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ARCHITECTURE FOR MULTIPLE CHANNEL ACCESS 
TO APPLICATIONS 

5 

Field of the Invention 

The present invention relates to computer 
systems and, more particularly, to methods and 
systems for the integration of multiple types of 
10 devices for accessing Internet based applications. 

Background to the Invention 

The growth .of interest and participation in 
the Internet has led to a clamor for more ways of 

15 accessing Internet based applications. Consumers now 

use the Internet for tasks which a mere five years 
ago were considered to be the sole territory of the 
personal computer. Web based applications now allow 
people to store, access, modify, and retrieve, among 

20 others, their calendars, bank transactions, e-mail, 

telephone messages, appointments, and contact lists 
through the Internet . These same consumers now want 
the ability to access these Internet based 
applications anywhere using physically smaller 

25 devices. Of course, this must be done without 

compromising the lowest common denominator among most 
consumers — the personal computer (PC) based 
Internet browser. Accordingly, any solution must 
preserve the Internet application's workstation 

30 centric core. However, at the same time these 

applications should also allow such diverse devices 
as WAP (Wireless Application Protocol) enabled mobile 
telephones, palmtop computers, regular telephones, 
and personal digital assistants (PDAs) to access its 

35 functions. 
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To answer the above need, a number of 
solutions have been attempted with mixed results. 
Web based applications have been customized to run on 
these smaller devices with the devices accessing them 
5 through specific web portals. Such an approach is, 

unfortunately, quite expensive. Not only is a 
rewrite of the application required for each and 
every device type, there is also no guarantee that 
the rewritten application will have the functions of 
10 the original application. 

Another attempted solution is the shrinking 
of web browsers so that they can run on these 
devices. Unfortunately, the applications, optimized 
for PCs, are not suitable for such an approach. The 
15 small screen (if any) and the limited capabilities of 

the devices have led. to consumer frustration with 
this approach. Furthermore, the relatively slow, 
speed of the connection between the device and the 
portal, normally through a wireless modem, also leads 
20 to consumer frustration. 

Another drawback to such devices is the 
lack of scripting capability of the browsers of such 
devices. A further wrinkle to the problem is the 
need to customize each attempted solution to a 
25 specific device platform. A solution which may work 

properly with a WAP enabled cellular telephone may 
not work properly with a PDA and vice versa. Also, 
what may work with a cellular telephone is almost 
guaranteed not to work with a regular telephone 
30 connected to a PSTN (public switched telephone 

network) . 

A suitable solution to the above should be 
flexible, scalable, and must work equally well with 
any and all devices which are currently being used to 
\5 access the Internet. Such a solution should also be 
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transparent to the user and should facilitate rather 
than hamper a user's access to the Internet 
application. 

5 Summary of the Invention 

The present invention provides systems and 
methods which allow an Internet based application to 
be accessed by any device capable of accessing a 
specific portal without requiring an intensive 

10 rewriting of the application. Indeed, while an API is 

desirable, no access to the application's source code 
or application programming interface (API ) is 
required. A three layered system is placed between 
the application and the accessing device. The first 

15 layer is an AMI (Application Mediation Interface) 

component directly connected with the application. 
This application component is able to directly access 
any data stored by the application. A second layer 
is a broker layer which mimics the general user 

20 interface logic of the application. The broker layer 

emulates the UI (User Interface) workflow of the 
application and, when required, requests data from 
the application through the application component. 
The third layer is a DMI (Device Mediation Interface) 

25 component which communicates directly with the end 

user device. The DMI component receives data from the 
broker layer and converts this data into user 
interfaces, data screens,, or prompt screens which the 
end user device can both understand and present to 

30 the end user. * 

In a first aspect the present invention 
provides a system for enabling multiple types of end 
user devices to access an application, said system 
comprising: 

35 - an AMI (Application Mediation Interface) 
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component communicating with said application; 

- a DMI (Device Mediation Interface) component 
communicating with said devices; and 

- a broker module communicating with said DMI 
5 component and with said AMI component, 

wherein 

- said DMI component converts end data received 
from said broker module into a format suitable 
for said devices; 

10 - said DMI component transmits replies to 

prompts from said broker module based on an end 
user's input into said devices; 

- said broker module emulates a sequence of 
events and decisions followed by said 

15 application; 

- said broker module provides application data 
functions from said AMI component based on said 
broker module emulating said application; 

- said AMI component receives requests from said 
20 broker module and transmits replies to said 

requests to said broker module based on original 
data from said application; and 

- said broker module transmits end data to said 
DMI component, said end data being based on at 

25 least one factor chosen from the group 

comprising : 

- said broker module' s emulation of said . 
application; and 

- application data received from said AMI 
30 component. 

In a second aspect the present invention 
provides a method of enabling multiple types of end 
user devices to access an application, said method 
comprising: 

35 - emulating a sequence of events and decisions 
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followed by said application at a broker module 

- requesting application data from an AMI 
(Application Mediation Interface) component 
based on an emulation of said application by 

5 said broker module, said AMI component 

communicating with said application; 

- transmitting application data requested to 
said broker module from said application server, 
said application data being based on original 

10 data received from said application by said AMI 

component / and 

- transmitting end data to a DMI (device 

j» Mediation Interface) component, said end data 

Ni being based on at least one factor chosen from 

»ii 15 the group comprising: 

'■jf . ' ' " said broker module's emulation of said 

:y . application; 

!i - application data received from said AMI 

j'il component; 

rU 20 - converting said end data at said DMI 

|=5 component into a format suitable for an end 

□ user device communicating with said DMI 

component . 

25 Brief Description of the Diagrams 

A better understanding of the invention may 

be obtained by reading the detailed description of 

the invention below, in conjunction with the 

following drawings, in which: 
30 Figure 1 is a block diagram of a system 

according to the invention; 

Figure 2 is a block diagram similar to 

figure 1 but with multiple broker modules and 

multiple applications; and 
35 Figure 3 is a detailed block diagram of the 
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system whose implementation is described below. 

Detailed Description of the Preferred Embodiment 

Referring to Figure 1, a block diagram of 
5 a system in accordance with the invention is 

illustrated. An Internet based application 10 
communicates with an AMI (Application Mediation 
Interface) component 20. Coupled to the AMI 
component is a broker module 30 which, in turn, is 

10 coupled to a DMI (Device Mediation Interface) 

component 40. The DMI component 4 0 communicates with 
an end user device 50. The broker module .30 is 
unique to each application as it reproduces the 
workflow or the top level logic of the application 

15 10. However, the AMI component 20 abstracts the data 

of the application 10 so that, when required, the 
broker module may request application data from the . 
application 10 through the AMI component 20. This 
application data is then converted and/or added to by 

20 the broker module prior to being passed on to the DMI 

component 40. The DMI component 4 0 is equipped to 
receive this end data and convert such data into a 
format suitable for whichever end user device is 
connected to it . 

25 The above scheme does not compromise the 

Internet capability of the application 10. As can be 
seen in Fig 2, the invention can accommodate multiple 
applications, multiple end user devices, and still 
allow regular personal computers access to the 

30 applications. From Fig 2, multiple applications 10A, 

10B, 10C, and 10D are communicating with the AMI 
component 20. For each application, a separate 
broker module is available. Broker 30A corresponds 
to application 10A, broker 30B corresponds to 

35 application 30B, broker 30C and broker 30D correspond 
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to applications C and D respectively. Also, multiple 
devices can be connected to the DMI component. 
Device 50A is a palmtop PC, device SOB is a WAP 
enabled, cellular phone, device 50C is a telephone 
5 connected to a PSTN, and device SOD is a PDA. The 

Internet 60 also connects a regular PC 70 with the 
applications 10A-10D. 

It should be noted that each of the end 
user devices 50A-50D communicate differently with the 

10 DMI component and each one requires a different data 

format. The palmtop PC can be connected by means of 
a regular modem while the PDA can be connected by a 
wireless modem. The WAP cellphone can be connected 
by its wireless link to the service provider while 

15 the telephone 50C is connected by a regular telephone 

line and a suitable interface. . 

In a specific implementation, the broker 
module functions are accomplished by the use of a 
script written in an XML (extended markup language) 

20 derived markup language MCML (multi-channel mark up 

language) . Each script follows and details the 
workflow of the application for which it is written. 
When required, the script, through a machine running 
it, calls for data from the AMI component. The 

25 script is device independent and AMI component 

independent. However, as noted above, it details the 
workflow or top level logic (events and decisions) of 
the application. Thus, the script will have the user 
prompts, the choices associated with such prompts, 

30 user input fields, data delivery, and the flow 

decisions associated with such options. The script, 
will, however, not mimic the deep functions of the 
application. It is simply a data delivery mechanism 
-- it prompts, receives, and delivers data to the end 

35 user through the DMI component. To do this, it 
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requests and receives data from the AMI component. 
It then reformats and/or adds to the data before 
sending it on to the DM I component. 

The AMI component is a stateless module in 
5 that it does not store nor even care about what state 

or step the application is in. What the AMI 
component does is to receive the broker module's 
requests and fulfills those requests by interfacing 
with the application. 

10 The DMI component is essentially a 

converter — it receives data from the broker module 
and converts that data into a format suitable for 
whatever device is requesting it. Thus, if the end 
user device is a telephone 50C, then the DMI 

15 component converts the data into a Voice XML document 

and funnels it to a text-to-speech converter so that 
the data may be read to end user. Conversely/ if the 
device is a WAP enabled cellphone, the data is 
converted into a WML (WAP markup language) document 

20 and transmitted to the end user cellphone. Thus, the 

data is now in a format which can be read and 
understood by the end user device. Similarly, if the 
data sent to the end user requires an input from an 
end user, the document produced by the end user 

25 device is converted to a format suitable for the 

broker module. Thus, if the device is the PSTN phone 
50C in Fig 2, the end user either speaks the required 
input or enters it through the keypad. If spoken, 
the end user's voice is converted, through a voice 

30 recognition system in the DMI component, into a Voice 

XML document. This is then converted into a format 
recognizable by the broker module. 

To manage security and user authentication, 
an authentication manager is deployed in the system. 

35 Such an authentication manager receives the user's 


13499ROUS01U 9 

credentials such as, name, password and authenticates 
them. Once authenticated, a session manager, 
implemented within the broker module, manages that 
user's transactions. The session manager can serve a 
5 twofold duty — not only does it keep track of the 

user's actions but it would store the state that an 
application is in. Since the AMI component is 
stateless and since most applications are state , 
driven, the session manager will store and monitor 
10 the application's state. Because of this, it is 

simpler for the AMI component to retrieve data from 
the application. As an example, if data A can only 
be accessed in the application by passing through 
states Al, A2, and A3, then an AMI component, not 
15 having any states, would be hard pressed to find such 

data. The AMI component may, in a single session, 
have to always go through those states just to keep 
accessing the data A. However, if the application is 
already in state A3 and the session manager has saved 
20 this state and has kept the application in this 

state, then any other time the AMI component requests 
data A, it would be ready. 

To further clarify, the broker module block 
uses the MCML language in which an MCML flow 
25 describes a set of states, to be interpreted by a 

finite state machine (FSM) . These states represent 
device-independent "forms" which may contain 
"widgets". The DM I component or Device Adaptor (DA) 
implicitly implements the FSM and dynamically 
30 translates these states to the target devices' mark- 

up language. 

The syntax blocks representing states, 
stored in one or more MCML documents, are implemented 
using XML, and can thus be validated. An application 
35 workflow consists of one or more linked MCML 
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There are different types of MCML blocks. 
These can be : 

• Text processing block 
5 • Menu processing block 

Getlnput processing block 

• UserDefined processing block 
Blocks can contain tags that may not be 

used by all devices. It is up to the translating 

10 process to select the tags appropriate to the target 

device. This allows the application flow writer to 
fine-tune application behaviour to suit devices with 
special capabilities. For example, some tags control 
telephony features which are not useful for HTML 

15 devices, but which may be useful for a Voice XML 

device. In that sense, some tags may be redundant in 
MCML, and would be filtered to produce the device- 
targeted documents. 

MCML documents can be produced or generated 

20 using any text editor. It is suggested that a 

validating editor or parser be used however, to 
ensure correctness. Alternately, the Saxon XML parser 
(or any other compliant XML parser) can be used to 
validate the MCML based on the DTD. 

25 Each application enabled by the multi- 

channel system requires an MCML flow, which can be 
implemented as one or more MCML documents. These 
documents should reside in a dedicated directory to 
avoid the risk of name clashes with other 

30 applications' MCML files. For example, for an expense 

reporting application, the MCML files may be called: 
.../ExpenseReporting/main.mcml 
.../ExpenseReporting/dataEntry .mcml 
.../ExpenseReporting/dataRetrieval .mcml 

35 The application' s flow is abstracted into a 
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series of linked states, represented by MCML blocks 
within MCML documents. States consist Of generic 
widgets, as detailed below. These are translated into 
the target device-specific widgets by the device 
5 adaptor, once all dynamic content, if any, has been 

inserted by embedded Java method calls. 

Placeholders for EJB (Enterprise Java Beans 
used to implement a portion of the AMI component or 
application adaptor) and local class calls can 

10 represent dynamic content. Special tags specify the 

method name and parameters required. The local or 
remote classes are then called through a 
filter/macro-processor class that returns an MCML 
block (a string) . This block replaces the place 

15 holder tag, and processing continues, with the 

eventual XSLT translation of the entire MCML document 
into the target mark-up language page, which Is then 
forwarded to the client. 

In one implementation, the following 

20 guidelines, standards and subsystems were used : 

1. J2EE standard (Sun Microsystems) 
compliant application server. 

2. SAXON 5.4.1 XSLT/XML processor. 

3. Web Logic Server 5.1 provides the 

25 application server and container framework 

for all classes. The Commerce Server 
provides the Web-based Personal Interaction 
Centre (PIC is MASP' s (Managed Application 
Services Platform) name for a portal) 

30 features upon which the multi-channel PIC 

(not described in this document) is based. 

4. Each application's UI flow must be 
described by a specific set of MCML 
documents . 

35 5. An XSL style sheet per channel type 



13499ROUS01U 12 

(VoiceXML, WML, HDML, etc) is required to 
translate the MCML to the target mark-up 
language . 

6. A Device Adaptor (DA) servlet is used 
to dynamically generate Voice XML / WML / HTML 
or other pages using SAXON XSLT to 
translate the MCML document/script. 

7 . Error handling is done through Java's 
remote exception mechanism. AMI Components 

10 throw exceptions that are caught and 

processed by the DA. 

Ideally, the following conditions are to be 
0 applied in implementing the system: 

';! 1. All E JB' s and classes that generate 

y 15 dynamic content within the MCML flows must 

p be stateless session beans that are written. 

4 to conform to the EJB documentation for 

[ A multi-channel access. 

U 2. Every request from devices must carry a 

y 

sY 20 session ID within URL and the current block 

3 name . 

3 . Caching may be done by the DA to avoid 
latency in reloading and translating MCML. 
Default application flow behaviour and 
25 default block parameters can be set in a special MCML 

block. 

The following (global) properties can be 

set : 

1 . Timeout in seconds for user input 
30 response . 

2. Number of prompt repetitions before 
failure. 

3. Global URL prefix. 

4. Name of starting block. 

35 5. Name of default error processing block. 
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6. Name of exit/abort block. 

7. Session timeout. 

Example: 

<! --(default settings) — > 
5 <globalproperties> 

<property name=" timeout" type="int" value="30"/> 
<property name="repeatnum" type="int" 

value="3"/> 

<property name="systemURL" type="text" 
10 value="www. nortelnetworks . com"/> 

</globalproperties> 

MCML states can be categorized into the 
following types of blocks: 

• Text display; 
15 • Menu options; 

• Get user input; 

• User-defined (method call) . 

A complete MCML application flow must also 
include other descriptions, such as error handling, 
20 version definitions, and embedded comments. These can 

be categorized as follows: 

• Global properties; 

• Error handling block; 

• Version description; 
25 • Copyright description; 

• Default settings - it includes timeout and other 
configuration information; 

• Disconnect block - to handle hang-up events during 
telephony access. 

30 MCML inherits its syntactic constructs from 

XML. Reference to XML specification should be made 
for in-depth information on syntactic issues. The 
MCML is defined in Backus-Naur Form (BNF which is a 
generic meta-language used to describe computer 

35 language) format as follows: 
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ApplicationFlow :: = <?xml version= "1;0"?> 
<mcml> 

<applicationname/>application name 
5 <copyright>copyright description</copyright> 

<version>version description</version> 
(default settings) 

<globalproperties> (properties) </globalproperties> 
<errorhandle> (processing block 

10 name) </errorhandle> 

<startblock> (processing block name) </startblock> 
<endblock> (processing block name) </endblock> 
(FSMflow) 
</mcml> 
15 deafultsettings : := 

<defaultsettings> 

<timeout/> timeout 

</def aultsettings> 
20 properties : := <properties> (property) ?</properties> 

property : := 
<property> 

<name/>property name 

<type/> (int I long I double 1 float | string I 

25 date I time) 

<size/> size of the property 
<value/> value of the property 
<def ault/>def ault value 
</property> 
30 default definitions : := 

<default> 

(properties) 
</default> 
FSMflow : := 
35 <FSMFlow> 
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(processing block) * 
</FSMFlow> 


Processing block : := 
5 TextBlock I MenuBlock I GetlnputBlock | 

UserDef inedBlock 

blockbody : := 

(Text block I Menu block I Getlnput block I List 
block I UserDefined block) 

10 MCML text processing blocks allow the 

display of text. This content can be either 
dynamically generated by an EJB or class, or can be 
static. Text blocks can also define buttons, for use 
with WAP browsers. These are not used in Voice XML. 

15 The grammar is as follows: 

Text block : := 

<block blocktype-"TextBlock" blockname="blockname"> 
[ (action) ] 

<properties> (property) ?</properties> 
20 <prompt> (Message) ?</prompt> 

<buttonsettings> (buttonsetting) *</buttonsettings> 
// for WAP 

(<text>(text content) </text>) * 
<nextblocks> 
25 (<hitbutton name="buttonname" 

goto="nextblockname"/>) * 
</nextblocks> 
</block> 
action : := 
30 <action> 

<method name="methodname" [ type="ejb" ] 
inter face=" inter facename" [ jndi=" jdni-path"] > 
<params> 

(<param name="param-name H type=" text"/>) * 
35 </params> 
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<result name="result"/> 
</method> 
</action> 

text content :: = [$ (property name) I user-defined 
5 text] 

MCML menu blocks generate a list of choices 
on the device. When the user selects one, the FSM 
will go to the associated next state. Menu choices 

10 can cause variables to be set. These variables are 

typically used to maintain state and are managed by 
the DA/FSM. These are saved using the state manager 
to allow multiple simultaneous sessions. The menu 
items may be static or dynamically generated by 

15 embedded method calls. 

The XML description of this processing 
block is as follows: 
Menu block : := 

<block blocktype="MenuBlock" blockname="blockname"> 
20 <properties> (property) ?</properties> 

// not currently used 
<prompt> (Message) ?</prompt> 

// menu title string 
<menuitems> 

25 (<menu title="your menu name" " id=" your menu 

id"/>)? //the items ; 
< /menu it ems > 
<choices> 
(<nextblock id="your menu id" 
30 goto="nextblockname" dtmf="digits"/> 

) ? // nextblock definitions must match 
menuitems 

</choices> 
</block> 


35 
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The MCML Getlnput processing block is used 
to collect the input data from a user. It posts an 
input form page on the device's browser first and 
then waits for the input. 
5 The syntax description is as follows: 

Getlnput block : := 
<block blocktype="GetInputBlock" 
blockname :=// blockname' / > 
<properties> 
10 (property) ? 

</properties> 

<prompt> (Message) ?</prompt> 

<buttonsettings> (buttonsetting) *</buttonsettings> 
// for WAP 
15 <form title="form title"> 

(formitem) ? 
</form> 
<nextblocks> 
<f illed>block name</f illed> 
20 <timeout>hangup block</timeout> 

<defaultblock>block name</def aultblock> // 
handle default case 

</nextblocks> 
formitem : : = 
25 <input name=" fieldname" 

type= (password | text I numeric) 
size=the length of the field 

title="fieldname"> 
default^ the default value for this field 
30 </input> 

The UserDefined MCML processing block is a 
data processing block. It does not post any page to 
the browser at all. It serves to make method calls 
to the application adaptor EJB methods, or optionally 
35 to local classes. The resulting output is saved in 
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FSM variables and can be used in subsequent 
processing blocks. The syntax description is as 
follows: 

UserDef inedblock : := 
5 <block blocktype="UserDef inedBlock" 

b 1 o c kn ame= "b 1 o c kn ame " > 
<properties> 
(property) ? 
</properties> 
10 [action] 

<nextblocks> 
<f ailure>block name</f ailure> 
<success>block name</success> 

<defaultblock>block name</def aultblock> // 
15 handle default case 

</nextblocks> 
</block> 

Integration Details 

20 For each application, an MCML flow must be 

written to describe the application workflow. The 
associated EJB' s and called classes must also be 
written, and the linkage between the MCML variable 
name, state names, and class names must be done so 

25 that these can work in concert. This means that the 

EJB's and MCML must be written with a knowledge of 
each other. 

To test, the EJB' s must be deployed on the 
application server, the MCML files stored under the 

30 public_html directory hierarchy, and the DA invoked 

using a client. 

The appropriate XSL style sheet can be 
passed as a request parameter to the DA, and the 
resulting target specific mark-up should be returned. 

35 
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Return Codes and Error Handling 

EJB's or other called classes return errors 
using one of two mechanisms: 

1. Throwing a remote exception, to be 
5 caught by the DA. 

2. Returning a null string instead of 
dynamically generated MCML. 

Both are handled in the same way: 
The DA will detect the error; 

10 - if the method called was not part of an EJB, or if 

it was not an authentication exception, or if the 
retries above failed, then the DA will go to the 
failure branch in the UserDefined block that called 
the method. This should point to a block that handles 

15 the error, either by notifying the user, or 

attempting retries; 

- the DA reserves a special variable called _error 
Message that is guaranteed to always contain the 
string returned by the last exception caught. 

20 

Example Usage 

Two examples of MCML code follow: 
<?xml version^ "1.0"?> 
<!-- filename: calendar .mcml -> 
25 <! — Date: August 22, 2000 — > 

<! — The following MCML document describes a Calendar 
application workflow. 

note: It assumes authentication is 

passed. 

30 The description of workflow is as 

follows : 

1. Calendar application welcome page 

(Text) 

C: Welcome to the Calendar 

35 application. 
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goto 2 ask for date 

2. Ask for the appointment date 

(Getlnput) 

C: Please say the appointment date. 
5 goto 3 get summaries 

3. Get the summaries of the specified 
date (UserDef ined) 

Call EJB to get summaries for the 

specified day 

10 save summaries in somewhere else. 

got 4 play summaries. 

4. Say the summaries (Menu) 

repeat goto 4 " 

detail goto 5 ask for the 

15 specified time 

other day goto 2 ask for date 

.5. Ask for time (Getlnput) 
goto 6 to get the detail 

6. Get the detail (UserDef ined) 

20 Call EJBs to get the detail and save it 

somewhere else. 

goto 7 to play the detail. 

7. Play the detail (Menu) 

25 repeat goto 7 

other appointment goto 5 ask for time 
other day goto 2 ask for date 

— > 

<mcml> 

30 <applicationname>Calendar</applicationname> 
<copyright>Nortel Networks Copyright. July, 
2 000</ copyright > 

<version>MCML Version 1 . 0</version> 
<!-- (default- settings) — > 

35 <globalproperties> 
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<property name=" timeout" type="int" 

value="30"/> 

<property name="repeatnum" type="int" 

value="3"/> 

5 <property name="systemURL" type="text" 

value="www. nortelnetworks . com"/> 

<property name="userid" type=" text M /> 
<property name=" pas sword" 
type= "password" /> 
10 </globalproperties> 
<errorhandle> 

<hangup blockname="hangupbiock"/> 
<error blockname="errorblock"/> 
</errorhandle> 
15 <FSMFlow> 

<block blocktype="TextBlock" 
blockname= "start " > 

<! — ask for date — > 
<text> Welcome to the Calendar 
20 application. </text> 

<nextblocks def aultblock="askf ordate"> 
<timeout goto="disconnect "/> 
</nextblocks> 
</block> 

25 <block blocktype="GetInputBlock" 

blockname="askfordate"> 

<! — ask for date --> 
<prompt> 

<message msgmode= "Voice XML" 
30 msgtype=" text" content="Please say the appointment 

date."/> 

</prompt> 
<f orm> 

<input name="date" type="date" 

35 title="date"/> 
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</form> 

<nextblocks def aultblock=" get summaries" > 
<! — demo goto hangup — > 
<filled goto="getsummaries"> 
5 <output name="date" type="date"/> 

</filled> 
</nextblocks> 
</block> 

<! — need a specific implementation using 
10 servlet or java class — > 

<block blocktype="UserDef inedBlock" 
blockname="getsummaries"> 
<properties/> 
<action> 

15 <! — method name="getSummaries" 

int er f ace= " com . nor t el . masp . mca .MCML . Cal endarWrapper " 
source="http: //localhost : 7001 " : — > 

<! — method name="makeE JBcall" 
interf ace="com. nortel .masp .mca .MCML .CalendarWrapper" 
20 source="http: //localhost : 7 001" — > 

<! — method name="getSummaries" 

type="ejb" 

interf ace="com. nortel .masp. mca. MyCalendarRemote" 
ejbhome="com. nortel .masp. mca .MyCalendarHome" 
25 jndi= "mca -MyCalendarHome" 

ejbhost="t3 : //localhost : 7 001" — > 

<method name=" get Summaries" type="ejb" 
interf ace="com. nortel .masp .mca .MyCalendarRemote" 
j ndi= "mca . MyCalendarHome " > 
30 <params> 

< ! --param 

name="remote=com. nortel .masp. mca .CalendarRemote" 
type="text"/ — > 

< ! — param 

35 name="jndi=mca.CalendarHome" type="text"/ — > 
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<param 

name="CalendarURL=http : //wleeyOO 6 . ca . nor t el . com" 
type="text"/> 

<param name="port=81 " type="text "/> 
5 <param na^le= ,? username=demo ,, 


type= !, text"/> 
type="text"/> 


<param name="password=new2day" 


<param name="date" type="text"/> 
10 </params> 

<result name="summariesmenu"/> 

</method> 
</action> 
<nextblocks> 

15 <success goto="saysummaries"/> 

< failure goto="noappointment "/> 
</nextblocks> 
</block> 

<block blocktype="MenuBlock" 
20 blocknarae="saysummaries"> 

{ $ s umma r i e smenu } 
</block> 

<block blocktype="TextBlock lr 
blockname="noappointment"> 
25 <properties/> 

<prompt/> 
<buttonsettings> 

<button buttontype="accept" 

label= lf back"/> 
30 <button/> 

</buttonsettings> 

<text>No appointment for this day</text> 
<nextblocks def aultblock="askf ordate"> 
<hitbutton name="back" 
35 goto="askfordate"/> 
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</nextblocks> 
</block> 

<! it needs a specific servlet or clas 
to implement this block - — > 

5 <block blocktype="UserDefinedBlock" 

blockname="getdetail"> 

<properties/> 
<action> 

<method name=" get Detail" type="ejb" 
interface="com.nortel .masp.mca.MyCalendarRemote" 
j ndi= "mca . MyCal endarHome " > 

<params> 

<param name="UID" type=" text*V> 
<param name="port=81 " type="text" 
15 <param name= "us ername=demo " 


10 


type="text"/> 
type="text"/> 


<param name= "password=new2day" 


</params> 

20 <result name="detail"/> 

</method> 
</action> 

<output><property name=" detail ,f 
type= f, text"/></output> 
25 <nextblocks> 

<success goto="saydetail"/> 
<failure goto="saynoappointment "/> 
</nextblocks> 
</block> 

30 <block blocktype="MenuBlock" 

blockname="saydetail"> 

<properties/> 
<prompt> 

<message msgtype=" text " content="your 
35 appointment is as follows: "/> 
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<message msgtype=" text " 
content=" { $detail } " /> 

<message msgmode=" Voice XML " 
msgtype="text" content^"- Please choose one of the 
5 following options: summary, another day, or 

repeat. "/> 

< /prompt > 
<menuitems> 

<menu title="repeat" id="repeat "/> 
<menu title="back to summary" 
id= " summary" / > 

<menu title="another day" id="another 

day"/> 

</menui terns > 

15 <choices def aultblock="askf ortime"> 

<nextblock id="repeat" 
goto="saydetail"/> 

<nextblock id=" summary" 
goto="saysummaries'7> 
20 <nextblock id="another day" 

goto="askfordate"/> 

</choices> 
</block> 

<block blocktype="TextBlock" 
25 blockname="saynoappointment"> 

<! — ask for date — > 
<action> 

<method name=" toSpeakableDate" 
inter f ace=" com. nortel .masp .mca .MCML .MCMLutils "> 
30 <params> 

<param name="date" type="text"/> 
. </params> 

<result name="speakableDate"/> 
</method> 
35 </action> 
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<prompt> 

<message msgtype=" text" content="No 
appointment on { $speakableDate} "/> 
</prompt> 

<nextblocks def aultblock="askfortime"> 
<timeout goto="hangup"/> 
</nextblocks> 
</block> 

<block blocktype="TextBlock" 
bio ckname= "hangup " > 

<buttonsettings> 

<button buttontype="accept" 

label="OK"/> 
15 <button/> 

</buttonsettings> 

<text>Thank you for calling calendar 
application. Goodbye . </text> 

<nextblocks def aultblock="disconnect "> 
<hitbutton name= ,, 0K" 
goto="askfordate"/> 

</nextblocks> 
</block> 

<block blocktype="DisconnectBlock" 
25 blockname="disconnect"> 

<disconnect/> 
</block> . 
</FSMFlow> 
</mcml> 

30 


20 
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<?xml version= "1.0"?> 
<» — filename: IMAP4.mcml — > 
<!-- Author: T. Barake — > 
5 <! — Date: Sept 12, 2000 — > 

<! — The following MCML document describes a 
Messenger application workflow. 

note: It assumes authentication has 
occurred and stored in session manager 
10 Workflow states: 

MAIN 
Email main menu 

1- Get list of unread mail headers 

goto UNREAD 

15 2- Choose a mailbox - go to 

SETBOX 

3- Contact list _ goto 

CONTACTS 


20 


25 


30 


35 


messages 


displayed 


EXITtoIMAP 
UNREAD 

Menu of unread headers if any 
otherwise 
Display a message saying no unread 

uses : 

SELECT MAIN 
SELECT 

Display the detail 
uses : 

UNREAD MAIN 
SETBOX 

Menu of available mailboxes is 


SELECTBOX 


MAIN 
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SELECTBOX 

Menu of unread headers if any 
otherwise 

5 Display a message saying no messages 

uses : 

DETAIL MAIN 
DETAIL 

Display the detail 
10 uses: 

SELECTBOX MAIN 
CONTACTS 

Menu of contact headers if any 
otherwise 

15 Display a message saying no contacts 

uses : 

SELECTCONTACT MAIN 
SELECTCONTACT 

Display the detail on a contact 
20 uses: 

CONTACTS MAIN 

— > 

<mcml> 

<applicationname>Calendar</applicationname> 
25 <copyright>Nortel Networks Copyright. October, 

2000</copyright> 

<author>A. Barake</author> 
<version>MCML Version 1 . 0</version> 
<! — (default settings) — > 
30 <globalproperties> 

<property name=" timeout" type="int" 

value="30"/> 

<property name="repeatnum" type= n int" 

value="3"/> 

35 <property name="systemURL" type="text" 
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value="www. nortelnetworks . com"/> 

<property name="userid" type=" text "/> 
<property name= "pas sword" 
type="password"/> 
5 </globalproperties> 
<errorhandle> 

<hangup blockname="hangupblock" /> 
<error blockname="errorblock" /> 
</errorhandle> 
10 <FSMFlow> 

<block blocktype="MenuBlock" 
blockname="start"> 
<properties/> 
<prompt> 

15 <message msgtype=" text " 

content="Messenger eMail"/> 
</prompt> 
<menuitems> 

<menu title="l. Get unread mail headers 

20 id="l" /> 

<menu title-"2. Choose a mailbox" id="2 

/> 

<menu title="3. Contact list" id="3" /> 
</menuitems> 

25 <choices def aultblock="get " dtmf="true"> 

<nextblock id="l" 
goto- " FETCHUNREADHEADERS " /> 

<nextblock id="2" goto="SETBOX"/> 
<nextblock id="3" goto="CONTACTS"/> 

30 </choices> 

<! — button required EXITtoIMAP — > 
</block> 


35 


<block blocktype="UserDefinedBlock" 
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bloc kn ame= " FE T CHUNREADHEADERS " > 
<properties/> 
<action> 

<method name="getUnreadMessageHeaders" 

5 type="ejb" 

interface="com.nortel.masp.mca.Imap4Remote" 
jndi="mca. Imap4Home"> 

<params> 

<param name="mailbox=inbox" 
10 type=»text''/> <! — (java.lang. String mailbox) — > 

</params> 

<result name="unreadheadersitienu"/> 
</method> 

</action> 
15 <nextblocks> 

<success goto="DISPUNREADHEADERS n /> 
<failure goto= " NOME S SAGES "/> 
</nextblocks> 
</block> 

20 <block blocktype="MenuBlock" 

bio ckname= " DI S PUNREADHEADERS " > 
{ $unreadheader smenu } 
<nextblocks def aultblock="MAIN"> 
<hitbutton name="OK" 
25 goto="DISPDETAILS"/> 

<hitbutton name="back" goto="MAIN"/> 
</nextblocks> 
</block> 

<block blocktype="TextBlock" 
30 blockname="NOMESSAGES"> 

<properties/> 
<prompt/> 
<buttonsettings> 

<button buttontype="accept" 

35 label="back M /> 
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<button/> 
</buttonsettings> 

<text>No unread messages found</text> 
<nextblocks def aultblock="MAIN"> 
5 <hitbutton name="back" goto="MAIN"/> 

</nextblocks> 
</block> i 
<block blocktype="UserDef inedBlock" 
blockname="SETBOX M > 
10 <properties/> 

<action> 

<method name=" get Folder Names" type="ejb" 
interface="com.nortel .masp.mca. Imap4 Remote" 
jndi="mca. Imap4Honte"> 

15 <result name="foldernamesmenu"/> 

</method> 
</action> 
<nextblocks> 

<success goto="DISPFOLDERS"/> 
20 <failure goto="N0F0LDERS"/> 

</nextblocks> 
</block> 

<block blocktype="MenuBlock" 
blockname="DISPFOLDERS"> 
25 <• — selecting a folder here 

sends you to the header list fetch for that folder -- 
> 

<! — must return variable called 
foldername with correct folder in it — > 
30 { $ f oldernamesmenu } 

<nextblocks def aultblock="MAIN"> 
<hitbutton name="0K" 
go t o= " FETCHHEADERS " / > 

<hitbutton name="back" goto="MAIN" /> 
35 </nextblocks> 


13499ROUS01U 32 
</block> 

<block blocktype="UserDefinedBloc'k" 
blockname= " FETCHHEADERS " > 
<properties/> 
5 <action> 

<method name="getAllMessageHeaders" 

type="ejb" 

interf ace="com. nortel .masp.mca. Imap 4 Remote" 
j ndi = " mc a . Imap 4 Home " > 
10 <params> 

<param name=" { $mailbox } " 
type="text"/> <! — (java. lang. String mailbox) — > 

</params> 

<result name="allheadersmenu"/> 
15 </method> 

</action> 
<nextblocks> 

<success goto="DISPHEADERS"/> 
<failure goto="NOMESSAGES "/> 
20 </nextblocks> 

</block> 

<block blocktype="MenuBlock" 
blockname="DISPHEADERS"> 

<! — selecting a folder here 
25 sends you to the header list fetch for that folder — 

> 

<! — must return variable called 
foldername with correct folder in it — > 

{ $allheadersmenu } 
30 <nextblocks def aul tblock="MAIN"> 

<hitbutton name="OK" 
goto="DISPDETAILS"/> 

<hitbutton name="back" goto="MAlN"/> 
</nextblocks> 
35 </block> 
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<block blocktype=="UserDefinedBlock" 
blockname="DISPDETAILS"> 
<properties/> 
<action> 

5 <method name="getSelectedMessage" 

type="ejb" 

interface="com.nortel.masp.mca.Ima P 4Remote" 
jndi="mca. Imap4Home"> 

<params> 

10 <param name=" { $mailbox} " . 

type=»text»/> <«-- (j ava . lang . String mailbox, int 
mail_Id) — > 

<param name-" { $mail_ld} " 

type="int"/> 

15 </params> 

<result name="niessagedetails"/> 
. </method> 

</action> 
<nextblocks> 
20 <success goto="SHOWDETAILS"/> 

<failure go to="NOMES SAGES "/> 
</nextblocks> 
</block> 

<block blocktype="TextBlock" 
25 blockname="SHOWDETAILS"> 

{$messagedetails } 
<nextblocks def aultblock="MAIN"> 

<hitbutton name="OK" goto="MAIN"/> 
</nextblocks> 
30 </block> 

<block blocktype="TextBlock" 
blockname= " done " > 

<buttonsettings> 

<button buttontype= n accept" 

35 label="OK"/> 
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<button/> 
</buttonsettings> 

<text>Thank you for calling the Messenger 
application. Goodbye .</text> 

5 <nextblocks def aultblock="disconnect "> 

<hitbutton name="OK" 
goto= fl askfordate"/> 

</nextblocks> 
</block> 

<block blocktype=="DisconnectBlock" 
blockname="disconnect"> 

<disconnect/> 
</block> 
</FSMFlow> 
15 </mcml> 

Regarding the authentication manager, 
the authentication subsystem consists of the front- 
line authentication servlet, an L DAP directory shared 
with MASP, and application-specific authentication 
methods, implemented as part of the application 
adaptors' EJB. As noted above, the term application 
adaptor is interchangeably used to refer to the AMI - 
component . 

The role of the authentication servlet is 
to assign a session to the new user, and to maintain 
and manage this session for authenticated users in 
conjuction with the Device Adaptor (DA). It assigns a 
temporary session key during login and a session key 
after validation, and dispatches the request to the 
DA. The dispatched request is modified to suit the 
client browser's protocol and mark-up language, so 
that the DA can reply appropriately. 

A valid login will result in a session 
key being assigned and the storing of the user's 
login and password information in the session 


20 
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manager, for access by the application adaptors. 

The authentication servlet is responsible 
for timing out an inactive session as well as logging 
all login attempts made to it. 
5 The authentication servlet uses an SQL 

table to store and maintain an authenticated user 
session, and all information that is necessary to 
continuing that session. Session information specific 
to the display of pages, or the flow of control are 
10 stored in the Multi-Channel session manager in the 

DA. 

Since application adaptor E JB' s are 
designed to be stateless, they store all session 
state variables in the session manager. In the case 
15 of the authentication method within an e JB, its role 

is to create and store a client object to be used by 
the application access methods. 

The role of the authentication method 
associated with the application adaptor EJB' s is to 
20 create a session between the application adaptor and 

the back-end application, using the login credentials 
supplied to the DA and stored in the session manager 
by the authentication servlet. All application 
adaptor EJB methods assume that a valid client 
25 connection exists in the session. If this assumption 

is not true, the session manager throws an exception, 
which is caught by the DA. The DA will then call the 
EJB's authentication method to create the missing 
client connection, and will retry the call. This is 
30 possible since EJB's are stateless. 

By using this approach, EJB methods can 
be coded in a straightforward manner, and 
authentication is handled transparently to most of 
the code. There must, however, be a login method 
35 associated with each EJB, responsible to do the login 
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negotiation in response to the authentication 
exception. Such methods are potentially re-usable by 
multiple EJB's that access similar back-end protocols 
(for example IMAP4) . 

5 The following example only covers 

authentication examples for the following protocols- 
HTTP, IMAP, LDAF. Further authentication code will 
have to be written along the same lines to enable . 
single sign-on capability in applications that use 
10 protocols other than these. 

The system is accessed through a single 
URL, which points to the authentication servlet. This 
servlet is responsible for dispatching the request in 
a- manner appropriate for the requesting client 
15 browser (ex: WML, HTML, HDML, Voice XML). 

Ideally, the system would use the 
following requirements : 

- Each application adaptor EJB requires a 
special authentication method called 

20 "login"; 

- Application adaptor EJB methods must 
assume that the client connection to the 
application is stored in the session 
manager using a special name; and 

25 The special name for the authentication 

exception substring must be defined in the 
"util. constants" object. 
Normal communications between the 
application adaptor EJBs and their applications need 
30 an authenticated session. Whether or not this 

session has been initiated will be checked 
transparently (as the EJB tries to read the 
application client from the Session Manager) . if the 
client session cannot be found in the session 
35 manager, an exception will be thrown, which will 
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prompt the device adaptor to call the special login 
EJB method to set up this session. *< 

The following design guidelines and tools 
may be used: 

5 ■ x - . Java (Sun's JDK 1.2.2) is used for 

authentication EJB coding. 

2. The J2EE 2.0 specification for EJB 
interface and deployment is adhered to.. 

3. The application adaptor EJB' s are 
stateless, in that any device-side method 
call can be made at any time. State is 
maintained outside the EJB's, in the unique 
Session Manager. Therefore EJB's can be 
replicated and clustered. 

15 4 - Getting an authenticated session open 

to an application must be transparent and 
be able to re-login to the application if 
the previous application session has timed 
out . 

20 5. We want to keep the authentication 

mechanism in the application adaptor EJB as 
simple as possible. 

6. Authentication credentials and session 
dispatching occurs transparently to the DA 
and application adaptors, and is handled by 
the exposed authentication servlet. 
Ideally, the following conditions will also 


25 


apply 

30 


1. All EJB's must use the session manager 
to store state or instance information. No 
instance variables are allowed. The EJB's 
should be clusterable across different 
servers and operate with a single logical 
session manager. 
35 2 - Since the client objects stored in the 
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Session Manager may contain socket handles 
or files handles (and those handles are not 
transferable between machines), the device 
adaptor must always make calls to EJBs on 
5 one server only. 

Each application adaptor EJB will have a 
standard method call named "login" which will be used 
by the device adaptor to set up an authenticated 
session with the application. This method will take 
the standard parameters for all application adaptor 
EJBs: A session manager, and a property list which 
potentially contains additional parameters (if 
required) . 

That session will be read back from the 
15 session manager by each EJB method and used to 

communicate with the application. If the session is 
created successfully by the login method, it stores 
it in the session manager using a key name with the 
following format: 

Application name><loginClientSubstring> 
The "loginClientSubstring" is retrieved from the 
util . constants class. 

This allows the other EJB methods to 
retrieve the client connection with the application, 
using a standardized name, and also allows the DA to 
identify the exception that may be thrown if this key 
does not exist (no login has yet occurred) . The DA 
does this by parsing for the substring on all 
received exceptions, and it treats this particular 
exception as a special case. 

The following is a description of the steps 
taken by the authentication servlet when handling a 
request : 

• If incoming http request contains a system 
35 authentication key, check the key (see method below) . 
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If valid, pass the request on to the DA. 
• If there is no key associated with the'request, or 
if the key is invalid (it may have expired or may be 
an attack), challenge the user agent (client browser) 
5 as follows: 

• Save the incoming URL based on the 
generated key; 

• Generate a temporary key for this reply 
and forward with device-specific form to 

10 the user; 

• Call the dispatch method (see key 
generation description below) , to 
generate a device-specific login form by 
sending a request to the DA to translate 

15 login. mcml; 

• The dispatch method determines the type 
of client (WML, . Voice XML, HDML, or 
HTML). The default type is HTML 
(settable) ; 

• Record the WebLogicSession key returned 
from the DA; 

• Wait for reply. When received, check 
the validity of the temp key (see 
algorithm below) ; 

• Convert user id and password from 
numeric if required (for Voice XML) 

• Lookup the user id/password in the LDAP 

• If authentication succeeds, proceed 
below, otherwise, retry above 

30 • Restore the original URL 

• Delete temporary login key 

• Create a authentication session key 
(see key generation description below) 
and append to request 

35 • Replace authentication key with 


20 


25 


15 


13499ROUS01U 40 

WebLogicSession key returned from the 
login step 

• Add the userid and password to the 
request sent to the DA 
5 • Forward the request to the DA 

Two types of keys are possible — temporary and 
session key with the same contents otherwise. 
The steps in the key generation process may be as 
10 follows : 

• Encode an expiry date (set to 1 hour for session 
keys, shorter for temp keys, but configurable) 

• Encode a random number 

• Encode sender's IP (IPV4 or IPV6) 

• RSA sign a buffer containing the above 4 items. 

• Add the signature to the end of the key buffer 

• Base64. encode the buffer 

To validate the key, the process may take the 
following steps : 

• decode the key using Base64 decoding 

• Split the result into key and signature 

• Verify the key using the RSA signature. 

• Check key's age - if near expiry (within 10 
minutes) and it is a session key, reset the expiry. 

25 to another hour since this request counts as activity 

• Check that the sender's IP still matches that of the 
sender when the key was created. 

• Base further processing on the key type 
EJB login methods are required to connect 

to the back-end applications. The following is a 
template for such methods. 
EJB_wrapper (...) { 
try { 

AppEJB.method( SessMgr, parameterl, 
35 parameter2„.) ; 
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} 

catch InvalidXXX { : 
AppEJB. login ( SessMgr ); 

> 

5 } 

AppEJB { 

public methodl ( SessMgr, ... ) { 

client = SessMgr. getCurrentState () .get ( 
"AppCLIENT" ) ; 

} 

public method2 { SessMgr, ... ) { 

client = SessMgr. getCurrentState () .get ( 
"AppCLIENT" ) ; 

} 

public login ( SessMgr ) { 

AuthEJB. login (SessMgr, "AppCLIENT" ); 

} 

20 } 

AuthEJB { 

public login ( SessMgr, String app ) { 
// Get userid/password 

String, userid = 

25 sessMgr. getCurrentState () . get { "userid") ; 

String passwd = 
sessMgr. getCurrentState () . get ("password") ; 

// Connect to LDAP DB with userid/password (if 
necessary) 

// Lookup login credentials for user to login to 

app 

// Login to app 

ClientClass client = new ClientClass (userid, 
password) ; 

// Store client in sessMgr 
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SessMgr.getCurrentStateO .put ( a PP/ client 

) ' 

} 
} 

5 Concerning the session manager, the multi- 

channel architecture requires a session manager to 
maintain user and application session state and to 
provide dynamic state storage and retrieval services 
to the application adaptors. Since the application 
adaptors may be distributed over several servers, 
this service must be unique or replica-aware, and 
must serve all adaptors from the same central session 
repository. It may of course be implemented as 
distributed objects drawing from the same database. 
15 The actual mechanism and location of the session 

repository is transparent to application programmers 
(device adaptors and E JBs . ) The session manager 
object is passed by reference to all adaptors and 
EJBs. The session manager implicitly maintains a 
20 session ID. The session ID is embedded in the URL of 

all transactions with the client, since cookie 
support cannot be assumed. 

The session manager provides the following 
advantages : 

25 1- Provides user authentication into the 

application. The application adaptors can use the 
session manager to access applications. 

2. Dynamic session instance management 
that includes application specific instance fields 
(containers) , for example "session-id' 7 or 
"phoneNumber" . The session manager is used to store 
such dynamic session state information on behalf of 
the application and device adaptors. 

3. User profile management. The multi- 
channel session manager maintains the end-user 
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specific configuration (profile) which includes a 
list of provisioned applications with associated 
devices supported (properties) . Profiles are created 
and populated via the Management Interaction Center 
5 (MIC) and Business Interaction Center (BIC) interface 

in the completed system. MIC is a portal for the 
hosted application provider (HSP) to provision 
businesses to use MASP applications. BIC is the 
hosted business portal, used to manage their 
employees' access to hosted applications. The 
information is stored using Web Logic' s 
Personalization Server facilities, but would be 
manually populated for the interim release 
checkpoints, and for testing purposes. Web-based 
15 provisioning is assumed to be as provided by MASP 

1.1. Examples of configuration fields on a per-user 
basis would consist of: 

a) Predefined (by user) e-mail responses 

b) Predefined (by user) appointment 
20 summaries and locations 

c) List of enabled applications, and URI's 
on a per-channel basis 

d) APM related configuration information 

e) PIC preferences 

25 f) Application specific generic workflows 

(MCML) for multi-channel enabled 
applications, and for the PIC. 
g) Application specific time-out 
overrides. 

30 h) Sign-on enabling information (APM 

codes) . 

i)User preferences (for the PIC) such as 
application menu order, 

internationalization settings, ASR/TTS 
35 engine preferences. 
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The session manager may require the following : 

1. Location and linkage information for 
Personalization Server (or other) database. 

2. APM related interface information 
5 (server URI) . 

3. Resource file locations 

4. Session ID base 

5. Log file URI 

6. Default system time-out values 

10 

The following functions are available to the users of 
the session manager: 

1. Session creation, which returns a unique, 
session state object. 
15 2. Session retrieval via session manager. 

3. Put data into session -add an item to 
the session's property list,, name-value 
pair, where value is an object. 

4. Get data from a session - name-value pair 
20 property list. 

5. Delete a value from a session. 

6. Save a session state once the state has 
reached a new, consistent stage. 
7. Destroy the current session, i.e., 
25 logout. 


Internal methods: 

1. Update of profile information - retrieval 
from personalization server. 

2. Log-in to a given application (may use 
APM) . 

3. Log-out from a given application. 

4. Get a new unique session id. 


35 
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functionality described above by providing the 
following services: 

1. Create a unique user session upon single sign-on 
from PIC. 

5 2. Creation of a session, and retrieval of user 

profile data from personalization server database 
based on user credentials. 

3. Association with a session-id, suited for 
passing, as post data over http to the devices and 
adaptors (must fit within thin client browser data 
size constraints) . 

4. Read-write access to session information via 
session id. This includes user profile, and dynamic 
session data. 

5. Destruction of user session, through API call, or 
as a result of inactivity timeout. 

The session manager also manages the following data: 

1. Persistent user profile information: provisioned 
applications and associated devices supported, 
application specific generic workflows (MCML) , sign- 
on enabling information (APM codes), Pic related 
preferences . 

2. Non-persistent application session state and 
instance information. This data is application 
dependent and non-static. The EJB' s that make up the 
application adaptors can use the session manager to 
store state and session information as required. This 
data is subject to inactivity timeout constraints. 


The following design guidelines can apply: 
1. The session manager is necessarily a high-demand 
service, and requires an efficient implementation, 
which would include caching, passivation and 
35 clustering support. 
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2. Java (Sun's JDK 1.2.2) is, used for device and 
application adaptor coding. 

3. WebLogic Server 5.1 provides the application 
server and container framework for these classes. 

5 Weblogic Server's in-memory replication of 

HttpSession will be used to increase the throughput 
of session management. JDBC-based session management 
can also be considered in the future. The actual 
choice (in-memory replication vs JDBC) is transparent 
10 to the application layer (device adaptors and E JBs . ) 

The Personalization Server (v 2.0) provides the Web- 
based PIC features upon which the multi-channel Pic 
(not described in this document) is based. 

The session manager is ideally able to 
15 handle a large number of sessions concurrently, and 

must therefore use an efficient mechanism for data 
storage and retrieval . The limitations on performance 
are to be load tested and must concord with MASP 
specifications for number of concurrent multi-channel 
20 users. 

The DM I component or device adaptor (DA) 
can be implemented using the example provided below. 

It should be noted that the example 
provided uses a PSTN telephone as the end user 
25 device. 

It should also be noted that the ASR/TTS 
{text-to-speech) channel functionality is dependent 
on the VoiceXML implementation. 

Furthermore, since the voice channel has inherent 
30 limitations from a user-interface point of view, 


i.e. 


a) one-at-a-time menu selection capability, 
.b) limited data entry capability, 

c) limited (to approximately 100 words) vocabulary 
35 for acceptable speaker-independent recognition. 
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The user interface for this implementation 
has some inherent problems. The user interacts with 
the system using DTMF tones and speech. Typically, 
the system prompts the user with generated and pre- 
5 recorded text and sounds, and the user can respond 

with DTMF keystrokes or with spoken commands. The 
interface is analogous interactive voice response 
(IVR) call flows, but the menus may be made "flatter" 
to take advantage of the larger response range of ASR 
10 as opposed to DTMF. 

Some responses and prompts are standard for all 
applications, akin to the «n" or DTMF 

request in an IVR system: 
General guidelines: 
15 a. The user can say, "help" or "I don't understand", 

or "repeat" to obtain more information or an 
alternate prompt. , . 

b. Numeric responses can be entered via DTMF or ASR. 
Yes and No responses can be entered via DTMF as 1 or 

20 2 respectively. 

c. The user can say v hang-up" to exit the 
application at any time. 

d. Passwords and PIN's should only be entered via 
DTMF to avoid being overheard or misinterpreted. 

25 

System requests: 

a) The system prompts the user with sounds, pre- 
recorded text, or TTS generated text, as indicated in 
the MCML flow. 

30 b) Failure to respond within a timeout setting in 

the session manager will result in the prompt be 
rephrased, and if no response is received after a 
longer timeout, the application will disconnect. 

The multi-channel session manager maintains 

35 the end-user specific configuration. This 
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configuration information is used by the device 
adaptor to determine which applications -are enabled 
for a particular user and channel. 

Access to this information is through the 
5 session manager interface described elsewhere. 

A single device adaptor is required for the 
ASR/TTS channel. Its role is to translate the MCML 
application flow into a state machine instance to. 
drive the client. 
10 Th « device adaptor is called from the PIC 

application when the user selects an application from 
the main menu.-""X 

The( DMl) component executes the following 
steps when accessing an application : 
15 a ) Start a selected application session, given the 

application name, and the APM key obtained from the 
PIC's login. The following steps are then taken: 

- Logs-in to the selected application 

- If successful, this effectively starts a session 

20 for the user by calling the session manager to set-up 

an instance for the application session 

- Obtain the application's EJB coordinates for the 
application from the session manager 

- Obtains the MCML document from the session manager. 
25 - Translates the first state to a device specific 

template using the XSLT service and the device- 
specific style sheet. 

- Translate placeholders for dynamic content by 
making EJB calls. 

30 - Drive the application interaction including state 

transitions using EJB calls until the user exits the 
flow or a timeout occurs 

- Returns a status code to the calling application 
(PIC) . 

35 a) Force an instance of a session to exit, based on 
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its session ID. Clean up any instance data in the 
session manager* 

The design of the ASR/TTS component of the 
multi-channel subsystem involves two major sub- 
5 components: 

a) The application adaptor, which consists of a set 
of Stateless Session Beans that communicate with the 
applications. The adaptor also consists of a MCML 
(XML multi-channel application flow) document that 

10 specifies the Finite State Machine (FSM) states that 

the adaptors require to implement the functionality 
specified. 

b) The device adaptor, which drives the ASR/TTS 
engine VoiceXML implementation, in an application 

15 independent way. 

Both these adaptors make use of 
underlying infrastructure services. These include the 
session manager, XSLT and XML related classes, and 
the application server's container framework classes. 

The following design guidelines were used 
in this specific implementation : 


20 


25 


1. Java (Sun's JDK 1.2.2) is used for device and 
application adaptor coding. Java extensions not in 
the standard distribution are based on the jars 
delivered with Web Logic. 

2. Web Logic Server 5.1 provides the application 
server and framework for these classes (typically 
servlets) . The Personalization Server (v 2.0) 
provides the Web-based PIC features upon which the 
multi-channel PIC (not described in this document) is 
based. 

3. The device adaptors are application independent. 
The same device adaptor should work transparently 

35 with multiple applications. They implement specific 


30 
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instances of the state machine described in the 
application-specific MCML documentation/ Dynamic 
content generation links are contained in the MCML. 
It should be noted that the device adaptor is 
5 application independent. No assumptions about how the 

application flow can be made within that subsystem. 
This must be tested with different EJB' s and MCML 
flows . 

Furthermore, it should be clear that the 
10 MCML flows are necessarily device independent, in 

that they cannot depend on a client having certain 
capabilities beyond a common set of lowest common 
denominator controls, such as: 

Menus / selection lists; 
15 Accept and back buttons; 

Data entry fields, numeric,, 
alphanumeric, and password; and 

Labels and prompts. 

>As mentioned above, the DA (device 
adaptor or DMI component) is implemented as a 
servlet and the AA' s (application adaptors or AMI 
components) are implemented as EJB's. All calls (with 
an exception described below) are therefore remote 
object calls, and can return remote exceptions. 
25 Th e DA can also call local utility 

classes either to facilitate application adaptation, 
or to allow more MCML functionality. 

The DA is" responsible for generating 
calls to AA methods under the guidance of the MCML 
30 script currently running. Since the calls to the AA' s 

are generated dynamically, the called method 
signatures must be standardized. Additionally, the 
exception handling must be standardized to allow the 
DA to respond to business, system, and authentication 
35 errors. 
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The DA responds to exceptions in two distinct ways: 
l.It catches non-authentication exceptions, and 
allows the MCML to take the failure branch in the 
script - potentially allowing another MCML block to 
5 handle the error appropriately. 

1. Authentication exceptions cause the DA to call the 
AA's authentication methods, which is responsible for 
obtaining a user session with the application using 
the credentials stored in the session manager by the 

10 authentication servlet. There is a limit to the 

number of iterations the DA will try on a given auth- 
exception to avoid looping forever. Authentication 
exceptions are identified based on the returned 
string signature, which must contain a unique sub- 

15 string. 

As an example of a DA servlet, the 
following source code implements a servlet which 
transforms an MCL document into VoiceXML. 


20 /* 

*@version 1.0 
*/ 

package com. nortel .masp.mca . servlet; 
import java.io.*; 
25 import j avax . servlet . * ; 

import j avax. servlet .http. *; 
import java.util.*; 
import com.icl .saxon.*; 
import com. icl .saxon. output . *; 
30 import com. icl . saxon . expr .* ; 

import org.xml . sax . * ; 
import com. nortel . ma sp . mca . MCML . * ; 
import com. nortel .masp.mca. stateManagement . *; 
import com. nortel .masp.mca .util . * ; 
35 /** 
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* VoiceServlet . Transforms a supplied MCML document 
into VoiceXML 

* using the supplied stylesheet xmlServlet .xsl 
V 

public class VoiceServlet extends HttpServlet { 

private static final String MCML_VTABLE = 
"maspMultiChannelAccessSessionMCMLVTACBLE"; 

private static final String 
DEFAULT_LOGIN_METHOD_NAME_KEY = " loginMethodName" ; 

private static final String 
DEFAULT_INDEX_MCML_KEY ="def ault IndexMCML" ; 

static private final String 
DEFAULT_ERROR_HANDLING_MCML_KEY = 
"def aultErrorHandlingMCML" ; 

static private final int debug =1; 
static private final int testVersion = ec- 
static private final String I NVAL I D_US E R_MCML = 
McaProperties . getlnstance ( ) .getProperty ( "da . def aultln 
validUserMCML" , "mca/invaliduser.mcml") ; 

static private final String ERROR_HANDLING_MCML = 
McaProperties . getlnstance ( ) . getProperty ( "da . def aultEr 
rorHandlingMCML", "mca/errorhandler.mcml") ; 

static private final String INDEX_MCML = 
McaProperties . getlnstance ( ) . getProperty ( "da . def ault In 
dexMCML", "mca/pic.mcml") ; 

static private final String L OG I N_ME T HOD_NAME = 
McaProperties . getlnstance ( ) . getProperty ( "da . def aultLo 
ginMethodName" , "login"); 

static private final String START_BLOCK_NAME = 
"start"; 

static private final String BLOCK_NAME = "_b"; 
static private final String XML_SOURCE = "_x"; 

static private final String XSL_STYLE = "_1"; 
static private final int MAX COUNT = 3; 
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static private final String CONTENT_TYPE = 
"content-type"; ; 

static private final String MCA_HEADER = 
"mcaheader" ; 

5 

static private final String XSL_EXT =".xsl"; 
static private final String XML_EXT = " . mcml " ; 
static private final String DEFAULT_APP_PATH = 
McaProperties . getlnstance ( ) . getProperty ( "da . def aultMC 
10 MLAppPath", "mca/"); 

/** 

* doGet() - accept request and produce 
response<BR> 

* URL parameters : <UL> 

15 * <li>_x - URL of source document</li> 

* <li>_l - URL of stylesheet</li> 

* <li>clear-stylesheet-cache - if set to yes, 
empties the cache before running. 

* <li>URL format: 
20 /demo?uniqueID?_x=xxx ,mcml?_l=xxx .xsl?_b=start 

* </UL> 

* @param req The HTTP request 

* @param res The HTTP response 
*/ 

25 public void doGet (HttpServletRequest req, 

HttpServletResponse res) 

throws ServletException, IOException 
{ 

doPost(req, res); 

30 } ^ 

/ * * 

* doPost ( ) - accept request and produce 
response<BR> 

* URL parameters: <UL> 

35 * <li>_x - URL of source document</li> 
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* <li>_l - URL of stylesheet</li> 

* <li>clear-stylesheet-cache - if set to yes, 
empties the cache before running. 

* </UL> 

5 * @param req The HTTP request 


* @param res The HTTP response 
*/ 

public void doPost (HttpServletRequest req, 
10 HttpServletResponse res) 

throws ServletException, IOException 

{ 

Log. log (Log. DEBUGGING, this . getClass () , 
PrintUtil . convertToString (req) ) ; 
15 String source = null; 

/*req.getParameter (XML_SOURCE) ;*/ 

. String style = null; 
/*req. get Parameter (XSL_STYLE) ; */ 

String blockname = null; 
20 /*req. get Parameter (BLOCK_NAME) ;*/ 

String querystr = req . getQueryString ( ) ; 
SessionStateManagerDef manager = 
S es s ionS tateManagerAbs tract Factory .makeManager (req, 
res) ; 

25 SessionState state = null; 

SessionState tmpState = new 
SessionState ( "tmpawewe233 66232 33 " ) ; 

boolean blnvalidUser = false; 

// Chech if the session is created or not. 
30 if ( Imanager . isSessionStarted ( ) ) 

{ // Create a new session and initialize 

it. 

initSession (manager) ; 

} 

35 state = manager . getCurrentState () ; 
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if (state == null) 
{ 

Log. log (Log. ERROR, getClass () , "st 

== null") ; 

5 blnvalidUser = true; 

state - tmpState; 

} 

. SessionState varTable = 
10 getVarTable (state) ; 

String sessionKey = state . getSessionKey () ; 
Log. log (Log. DEBUGGING, getClass ( ) , 
"SessionKey = " + sessionKey) ; 

Log. log (Log. DEBUGGING, getClass ( ) , 
15 "QueryString: : " + querystr) ; 

String cururlO; 
String absURL = 
req. get Parameter ( "absoluteURL" ) ; 

String hostURL = req. getScheme ( ) + "://" - 
20 req.getServerName ( ) + ":" 

+ req. getServerPort ( ) 

req.getServletPathO; 

if (absURL != null && absURL. equals ("1") ) 
{ 

25 cururlO = hostURL; 

} 

else 
{ 

cururlO = req.getServletPathO; 
30 } 

cururlO = manager . encodeURL (cururlO) ; 
hostURL = manager .encodeURL (hostURL) ; 
Log. log (Log. DEBUGGING, getClass () , 

"######## New version Servlet My Current URL 2 = 

35 + cururlO) ; 
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String id = 


56 

null; // temporary id for t 


Parameters et params = new ParameterSet ( ) ; 
5 // Check if there is a in cururlO 

params * put ( "id" , new 
StringValue (generateld ( ) ) ) ; 

varTable.put ("url", hostURL) ; 
ServletOutputStream out = 
10 res . getOutputStream ( ) ; 

Enumeration p = req . getParameterNames ( ) 
while (p .hasMoreElements ( ) ) 
{ 

String name = (String) p . nextElement ( ) 
15 String value = req. getParameter (name) 

if ( name. equal s (XML_SOURCE) ) 
{ 

source = value; 
String tmp = null; 
20 try 

{ 

tmp = 

(String) varTable. get (XML_SOURCE) ; 

} 

25 catch (Exception e) 

{ 

tmp — null; 

} 

if (tmp != null) 
30 { 

if 

(source. equals ( (String) varTable . get (XML_SOURCE) ) ) 

continue; 

} 

35 ) 
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else if (name .equals (XSL_STYLE) ) 
{ 

style = value; 
String' tmp = null; 
5 try 

{ 

tmp = 

(String) varTable.get (XSL_STYLE) ; 
10 } 

catch (Exception e) 
{ 

tmp = null; 

} 

15 if (tmp != null) 

{ 

if . 

(style. equals ( (String ) var Table . get (XSL_STYLE) ) ) 

continue; 

20 } 

} 

else if (name. equals ( BLOCK_NAME ) ) 
{ 

blockname = value; 
25 // do not put the blockname into 

parameterset until we start XSLT 

continue; 

} 

else if 

30 (name . equals ( "clear-stylesheet-cache" ) ) 

{ 

if (value . equals ( "yes" ) ) 
clearCache ( ) ; 

} 

35 if (value != null) 
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{ 

par ams .put (name . intern \) , new 
StringValue (value) ) ; 

Log. log (Log. DEBUGGING, getClass ( ) , name 
5 + »=" + value) ; 

var Table .put (name, value); 

} 

else 

10 Log. log (Log. DEBUGGING, getClass (), name 

+ " does not have its value."); 

} 

if (blockname == null && source == null) 
source INDEX_MCML ; 
15 if (source == null) 

{ 

try 
{ 

source = 

20 (String) varTable.get (XML_SOURCE) ; 

} catch (Exception e) 
{ 

source = INDEX_MCML; 

} 

25 params .put (XML_SOURCE, new 

StringValue (source) ) ; 

var Table. put (XML_SOURCE, source) ; 

} 

if (style == null) 
30- { 

try 
{ 

style = 

(String) varTable. get (XSL_STYLE) ; 
35 } 
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catch {Exception e) 
{ - 
// temporarily code 

####################### 
5 style = "html"; 

Log. log (Log. DEBUGGING/ 
getClass (), "XSL style sheet is not found. Using 
html.xsl as default!"); 
10 } 

params .put (XSL_STYLE, new 
StringValue (style) ) ; 

varTable.put (XSL__STYLE, style) ; 

} 

15 if (blockname ~= null) 

{ 

blockname = START_BLOCK_NAME; 
//source = INDEX_MCML; 
//varTable.put (XML_SOURCE, source) 
20 Log . log (Log . DEBUGGING, getClass () , 

"blockname == null, use start as block-name"); 

/ /params. put (BLOCK_NAME, new 
StringValue (START_BLOCK_NAME) ) ; 
} 

25 if (style. indexOf ("vxml") >= 0) 

cururlO = hostURL; 
if (cururlO . indexOf ("?") < 0) 

cururlO = cururlO + "?_dmy=l"; 
Log . log (Log . DEBUGGING, getClass ( ) , 
30 »=========================== curur ! o 

==============— =====\ n " + cururlO 

+ 

" \n===========================cururl 0 

; 

35 params .put { "cururlO", new 
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StringValue (cururlO) ) ; 

int innerCount =0; 
int outCount = 0; 
do 

5 { 


outCount ++; 
blnvalidUser = false; 
try 

10 { 

// Run the MCML filter to get the 
specified MCML block according to the given block 
name 

String mcmlText = null; 
15 do 

{ 

innerCount ++; 
blnvalidUser = false; 
logMsg ( "source =" + source); 
20 logMsg{"Jb =" + blockname) ; 

String path; 

if ( source. indexOf (".mcml") >= 0) 
path = 

getServletContext () . getRealPath (DEFAULT_APP_PATH + 
25 source) ; 

else 

path = 

getServletContext () . getRealPath (DEFAULT_APP_PATH + 
source + XML_EXT) ; 
30 MCMLFilter mcmlFilter = new 

MCMLFilter (path, blockname, manager) ; //varTable) ; 

try 
{ 

mcmlText = mcmlFilter . run ( ) 

35 } 
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catch (InvalidUserException e) 
{ / 
Log . log (Log . ERROR, 

getClass{), e) ; 
5 // Invalid user 

blnvalidUser = true; 
source = INVAL I D__USER_MCML ; 
blockname = 

10 S TAR T_B L O C K_NAME ; 

} 

catch (NoBlockException e) 
{ 


15 getClass { ) , e) ; 


ERROR HANDLING MCML; 


Log. log (Log. ERROR, 

blnvalidUser = true; 
source = 

blockname = 


20 START_BLOCK_NAME; 

} 

catch (UserDef inedBlockException e) 

{ 

String gotoStr = 
25 e.toStringO . substring (e . toString ( ) . indexOf ( " : " ) + 

1) .trim() ; 

System. out. println ( "###################### Us erDef ined 
Block 

handling################################## ########### 
30 #########"); 

System. out .println'(gotoStr) ; 
System. out. println ("################################# 

###########################################"); 

StringTokenizer gotoParams = 
35 new StringTokenizer (gotoStr, "&"); 
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params. clear {) ; 

par ams . put ( " curur 1 0 " , new 

StringValue (cururlO) ) ; 

params.putC'id",, new 
5 StringValue (generateld ())) ; 

String prevSource = source; 
String prevBlockname = 

blockname; 
10 while 
(gotoParams . hasMoreTokens { ) ) 

{ 

StringTokenizer 

oneParamToken = new 
15 StringTokenizer (gotoParams . nextToken ( ) , "=") ; 

- String name = 

oneParamToken. nextToken () ; 


20 (oneParamToken . hasMoreTokens { ) 


oneParamToken. nextToken () ; 


25 


30 


String value = null; 
if 


value = 


} 

if 


(name , equals (XML_SOURCE) ) 

value; 
null ; 


35 (String) varTable. get (XML SOURCE); 


source = 

String tmp = 

try 
{ 

tmp = 
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catch (Exception re) 

5 null; 


10 


25 


30 


tmp 


} 

if (tmp != 

null) 

{ 

if 

(source . equals ( (String) varTable . get (XML_SOURCE) ) ) 
continue; 

} 

15 } 


else if 


(name .equals (XSL STYLE) ) 


20 value; 
null ; 


(String) varTable. get (XSL_STYLE) ; 
catch (Exception re) 

null ; 

null) 


35 


style = 

String tmp = 

try 
{ 

tmp 

} . 
{ 

tmp 

} 

if (tmp != 
{ 
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10 


\ y. 20 

I'll 

□ 


if 

(style. equals ( (String) varTable.get (XSL_STYLE) ) ) 
continue; 

} 

} 


(name, equals (BLOCKJSTAME) ) 


value; 


else if 
{ 


blockname — 


// do not put 
the blockname into parameterset until we start XSLT 


innerCount = 
! ; y 15 0; 

Lli 

blnvalidUser 

: S| = true; 

u& continue; 

i;u } 

varTable.put (name, 

value) ; 

params. put (name. intern () , new StringValue (value) ) ; 

} 

if ( IblnvalidUser || 
25 (prevBlockname . equals (blockname) && 

prevSource. equals (source) ) ) 

throw new Exception (); 

} 

catch (Exception e) 
30 { 

Log . log ( Log . ERROR, 

getClass ( ) , e) ; 

blnvalidUser = true; 
source = 

3 5 ERROR_HANDL I NG_MCML ; 
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blockname = 

START__BLOCK_NAME ; 

} 

} while (blnvalidUser && innerCount < 

5 MAX COUNT) ; 


if (innerCount >= MAX_COUNT) 
10 { 

innerCount = 0; 

throw new Exception ( "Block {" + 
g blockname + ") is not found in " + source); 

4 } 

U 15 pa rams .put ( BLOCK__NAME , new 

jf StringValue (blockname) ) ; 

4 yar Table .put (BLOCKNAME, blockname); 

a apply (style/ mcmlText, params, req, 

y res, state) ; 

U 20 } 

1 catch (Exception e) 

3 { 

varTable .put ( "_errorString" , 

e. toString () ) ; 

25 Log . log (Log . ERROR, getClass(), e) ; 

if 

(source . indexOf (ERROR_HANDLING_MCML) >= 0) 

blnvalidUser = false; 

else 

30 { 

blnvalidUser = true; 
source = ERROR_HANDLING__MCML; 
blockname = START_BLOCK_NAME; 
params. clear () ; 
params.put ("cururlO", new 


35 
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StringValue (cururlO) ) ; 

params . put ("id", new 
StringValue (generateld { ) ) ) ; 

params. put (XML_SOURCE, new 

5 StringValue (source) ) ; 

params. put (XSL_STYLE, new 

StringValue (style) ) ; 

/ /params .put ( BLOCK_NAME , new 
10 StringValue (blockname) ) ; 

) 

} 

//params = createNewParams (blockname) ; 
} while (blnvalidUser && outCount < 
15 MAX_C0UNT) ; 

manager . saveState ( ) ; 
} ' - ■ 

private void initSession( SessionStateManagerDef 
manager) 
20 { 

manager . startSession ( ) ; 
SessionState state = 
manager. getCurrentState () ; 

state .put (DEFAULT_LOGIN_METHOD_NAME_KEY, 
25 LOGIN_METHOD_NAME) ; 

state. put (DEFAULT_INDEX_MCML_KEY / 

INDEX_MCML ) ; 

state .put ( 
DE FAULT_ERROR_HANDL ING__MCML_KE Y , 
30 ERROR_HANDLING_MCML) ; 

} 

* getServletInfo<BR> 

* Required by Servlet interface 
35 */ 


10 
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public String getServletlnf o { ) { 

return "Calls SAXON to apply a stylesheet t 
a source document"; 
} 

5 /** 

* Apply stylesheet to source document 
*/ 

private void apply (String style, String source, 

ParameterSet params, 
HttpServletRequest req, 
HttpServletResponse res, 
SessionState variable) 
throws SAXException, j ava . io . IOException 

15 { 

ServletOutputStream out = 
res . getOutputStream ( ) ; 

if (style==null) 
{ 

20 out.println("No style parameter 

supplied") ; 

return; 

} 

if (source==null) 
25 { 

out .println ("No source parameter 

supplied") ; 

return; 

} 

30 try 

{ 

StringWriter strout = new 

StringWriter () ; 

PrintWriter pout - new 
35 PrintWriter (strout) ; 
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try 
{ 

String contentType = 
(String) varTable. get (CONTENT_TYPE) ; 

5 

String mcaHeaderFileName = 
(String) varTable . get (MCA_HEADER) ; 

String mcaFilePath = 
getServletContext ( ) . getRealPath (DEFAULT_APP PATH + 
10 mcaHeaderFileName) ; 

FileReader in = null; 
try 

{ 

in = new 

15 FileReader (mcaFilePath) ; 

} 

■ catch (FileNotFoundException 
{ 

varTable . put ( "_errorS tring" , e.toStringO ); 
20 throw e; 

} 

Buf feredReader bufln = new 

Buf f eredReader (in) ; 

// Read the header 
25 String rdln; 

while ( (rdln = 
buf In. readLine ( ) ) != null) 

{ 

pout .println (rdln) ; 

30 } 

// set content type 
res . setContentType (contentType) ; 

} 

catch (Exception e) 
35 { // If there is no content-type 
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passed from sessionState, we hardcode it here. 
/////////////////////////////////////// f ///////////// 
/////////////////////////////////////// 

Log. log (Log. DEBUGGING, getClass() , 
5 "####### content-type and mcaheader from auth 

servlet are not correctly" ) ; 

if (style.indexOf ("vxml") >= 0) 
{ 

pout .println ("<?xml 

version=\"1.0\"?>") ; 


10 


res.setContentType ( "text /vxml") ; 
//setContentType ( "text/vnd.wap. wml" ) ; 
15 } 

else if (style.indexOf ("wml") >= 0) 
{ // for wml 

pout .println ("<?xml 

version=\"l . 0\"?>") ; 

20 pout.println("<!DOCTYPE wml 

PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\" 
\"http: //www. wapforum.org/DTD/wml_l . 1 .xml\">") ; 
res.setContentType ("text/vnd.wap. wml") ; 
//setContentType ( "text /vnd.wap. wml" ) ;*/ 

25 /*setContentType (details. getMediaType () ) ; 

} 

else if (style.indexOf ("hdml") >= 0) 
{ // for hdml 

pout .println ("<?xml 

30 version=\"1.0\"?>") ; 

pout.println("<!D0CTYPE wml 
PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\" 
\ "ht tp : //www . wapf orum . org/DTD/wml_l . 1 . xml\ " >" ) ; 
res . setContentType ( " text/x-wap . wml " ) ; 
35 //setContentType ("text/vnd.wap. wml") ; 
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setContentType (details . getMediaType ( ) ) ; 

} 

else 
{ 

5 res -setContentType ("text/html") ; 

//setContentType ("text/vnd.wap.wml") ; 
setContentType (details. getMediaType () ) ; 

} 

10 

///////////////////////////////////////////////////// 
/////////////////////////////////////// 

} 

PreparedStyleSheet pss = 
15 tryCache (style) ; 

StyleSheetlnstance ssi = 
pss .makeStyleSheetlnstance () ; 

OutputDetails details = 
pss . getOutputDetails ( ) ; 

20 details. setWriter (pout) ; 

ssi.setOutputDetails (details) ; 
ssi . setParams (params ) ; 
Log . log (Log . DEBUGGING, getClass () , 
"The input MCML as follows\n" + 
25 »=======:========= == = M cml 

BEGINNING=================\n" + 

source + "\n" + 


" ===================MCML END=-=============== " 

30 ) ; 

StringReader sourceReader = new 
StringReader (source) ; 

ssi . transform (new 
ExtendedlnputSource (sourceReader) ) ; 
35 String xmlstr; 
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xmlstr = strout . toString ( ) ; 

pout . close ( ) ; 

sourceReader. close ( ) ; 

Log. log (Log. DEBUGGING, getClassO , 

5 

"========The result 

after XSLT -====-\n" 

+ xmlstr 

10 + 

»\ n ============END===============" ) ; 

PostProcess postProc = new 
PostProcess (req, res, varTable) ; 

try 

15 { 

postProc. run (xmlstr) ; 

} 

catch (ServletException err) 
{ 

20 res.getOutputStream() .println( "Error MethodProcess : 

+ err . getMessage ( ) ) ; 

} 

} 

catch (SAXException err) 
25 { 

throw err; 
//out .println (err . getMessage ( ) ) ; 
} 

} 

30 // first get unique ID from URL 

// if there is no id=XX, it means this 
request is from a new session 

// if there is an id, then try to llok up 
MCMLVariables table, if the 
35 // table is not found. The request is 
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treated as a new request. 
/* 
*/ 

public SessionState getVarTable (SessionState 
5 state) 

{ 

if (testVersion == 0) 
return state; 

10 else 

return gMCML table; 

} 

/* * 

* Maintain prepared stylesheets in memory for 
15 reuse 
V 

private synchronized PreparedStyleSheet 
tryCache (String url) throws SAXException { 
String path; 
20 if (url .indexOf ( " .xsl") >= 0) 

path = 

getServletContext ( ) . getRealPath ( DE FAUL T__AP P_P AT H + 
url) ; 

else 

25 path = 

getServletContext ( ) . getRealPath (DEFAULT_APP_PATH + 
url + XSL_EXT) ; 

if (path-=null) 
{ 

30 throw new SAXException ( "Stylesheet " + 

path + " not found"); 
} 

PreparedStyleSheet x = 
(PreparedStyleSheet) cache. get (path) ; 
35 if (x==null) 
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{ 

x = new PreparedStyleSheet ( )''; 
x. prepare (new Extendedlnput Source (new 
File (path) ) ) ; 
5 cache. put (path, x) ; 

> 

return x; 

} 

10 private void logMsg (String loglnfo) 

{ 

Log. log (Log. DEBUGGING, getClass () , 

loglnfo) ; 

} 

15 private synchronized String generateld() 

{ 

Date tm = new Date ( ) ; 

Long In = new Long (tm. getTime ( ) ) ; 

return In . toString ( ) ; 

20 } 
/* * 

* Clear the cache. Useful if stylesheets have 
been modified, or simply if space is 

* running low. We let the garbage collector do 
25 the work. 

*/ 

private synchronized void clearCache ( ) 
{ 

cache = new HashtableO; 

30 } 

private static SessionState gMCMLtable = new 
SessionState ("12345676878999") ; 

private Hashtable cache = new HashtableO; 


35 
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To create proper EJB's which can be called 
from a DA, the following guidelines apply : 
1) All EJB methods must have the following signature: 
String EJBMethodName (SessionStateManagerDef 
5 manager, Properties params) 

throws CreateException, RemoteException, 
RemoveException 

Error handling: 

10 The Device Adaptor uses two ways to check whether the 

EJB call fails: 

Catch an exception from the EJB method 
Check if the return value is null 

15 Parameter passing: 

The method should get its associated 
parameters from the params Properties according to 
its corresponding parameter name. An alternate 
mechanism for data passing between method calls is to 
use the SessionStateManager. to store state data 
between calls. 

The following example illustrates the latter for 
getting a username and password: 
SessionState state; 

state = manager . getCurrentState () ; 
String username = (String) state . get ( "username" ) ; 
String password = (String) state . get ( "password" ) ; 

2) Each application EJB must implement an 
authentication method. The signature is as follows: 

String login (SessionStateManagerDef manager, 
Properties params) 

throws CreateException, RemoteException, 
RemoveException 
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This method is be called by the DA if the 
EJB method fail to find an active session in the 
Session State, as a result of the session manager 
throwing an exception which is passed up to the DA. 

5 

3) The proper MCML Syntax for making EJB or Class 
method call must be followed. 

The following MCML block gives an example of a call 
to the getSummaries in CalendarEJB 
10 <block blocktype="UserDef inedBlock" 

blockname="getsummaries"> 

<properties/> 

<action> ' 

<method name=" getSummaries " type^'ejb" 
15 interf ace="com. nortel .masp .mca . CalendarRemote" 

jndi="mca . CalendarHome" > <params> 
<param 

name="applicationURL=http: //wleey00 6 . ca. Nortel . com" 
type="text"/> 
20 <param name="port=81 " 

type="text"/> 

<param name="date" type=" text "/> 

</params> 

<result name= " summar iesmenu" / > 
25 </method> 

</action> 
<nextblocks> 

<success goto="saysummaries"/> 
< failure goto="noappointment "/> 
30 </nextblocks> 
</block> 

The "interface" attribute in the method element 
specifies the remote interface of an EJB. The "jndi" 
attribute specifies the JNDI_NAME for the EJB. 
35 To create classes which are callable from the DA 
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through the MCML scripts (or broker modules) , the 
following guidelines apply : * 

The DA may be used to invoke non-EJB 
classes, that can serve to enhance its functionality. 
5 These classes are called under the control of an MCML 

script, in the same way as an AA is called. 
These classes must follow the rules below: 

1) The methods must handle all the exception 
internally- The DA does NOT catch any exceptions 

10 thrown . 

2) The methods only have one input parameter - 
Properties params . 

All the parameter the method needs have 
to get from the passed properities. 
15 For example: toSpeakableDate ( ) is in the 

com. Nortel .masp .mca .MCML .MCMLutils class and is 
defined as follows: 

public String toSpeakableDate (Properties params) 
{ 

20 String theDateStr = params .getProperty ("date") ; 

String theRetiirnStr = null; 

* # 

return theReturnStr; 

} 

25 The associated MCML required is as follows: 

<block blocktype="MenuBlock" 
blockname="verif ydate"> 

<action> 
<method name=" toSpeakableDate" 
30 inter f ace="com. nortel .masp .mca .MCML .MCMLutils "> 

<params> 

<param name="date" type=" text " /> 
</params> 

<result name="speakableDate n /> 
35 </method> 
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</action> 

<prompt> 

<message msgtype="text" content="Your 
entered date is { $speakableDate} . "/> 
5 <message msgtype=" text" content="If it is correct, 

please say yes, otherwise say no."/> 
</prompt> 
<menuitems> 

<menu title="yes M id="yes"/> 
10 <menu title="no" id="no"/> 

< /menu it ems > 
<choices> 

<nextblock id="yes" 
goto=" getsummaries"/> 
15 <nextblock id="no" 

goto="askfordate"/> 

</choices> 
</block> 

An example of a simple MCML workflow that includes 
20 an EJB call action is provided below : ( test.mcml) 

<?xml version= "1.0"?> 
<mcml> 

<FSMFlow> 

<block blocktype="UserDef inedBlock" 
25 blockname= "start " > 

<action> 

<method name="getSummaries" type="ejb" 
interf ace="com.nortel .masp .mca .MyCalendarRemote" 
jndi="mca .MyCalendarHome "> 
30 <params> 
< ! — param 

name="remote=com.nortel .masp .mca . CalendarRemote" 
type="text"/ — > 

< ! --param 

35 name=" jndi=mca . CalendarHome" type=" text"/ — > 
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<param 

1 name="CalendarURL— http : //wleey00 6 . ca . nortel .com" 

type="text"/> 

<param name="port=81" 


type="text"/> 
type="text"/> 


<param name= M username=demo" 
<param name="password=new2day" 


type="text"/> 

10 <pararn name="date" type=" text"/> 

</params> 

<result name="summariesmenu n /> 
</method> 
</action> 
15 <nextblocks> 

<success goto="saysummaries"/> 
<failure goto="saynoappointment "/> 
</nextblocks> 
</block> 

20 <block blocktype= r, DisconnectBlock" 

blockname="dis connect "> 
<dis connect /> 
</block> 
</FSMFlow> 
25 </mcml> 

Regarding the application adaptor or the 
AMI component, an example is provided which utilizes 
the Calendar, E-mail and Contact List as the 
application. 

30 These applications may have the following 

capabilities : 


35 


Calendar Express: 

•get appointment summaries for a given date 
incrementally (limited by client's buffer size) 
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-get details (location, start, end, summary, text) 
for a given appointment based on start time 
- set an appointment for a given date and time using 
standard locations and summaries 

5 

E-mail: 

a) indicate how many unread messages you have 

b) set current mailbox 

♦get summary lines (headers) and message ids for 
10 unread or for all messages in a mailbox incrementally 

(limited by client's buffer size) 

d) get message text based on message id or next 
message in a mailbox or next unread message 

e) delete the current message (akin to voice mail 
15 deletes on the current message) 

f ) send standard reply to a message based on message 

id. 

Contact list: 

20 get contact list incrementally (limited by client's 

buffer size) 

•get detail information for a given contact name 

• send a standard message to a person in the contact 
list 

25 • prepare a receiver list for an e-mail based on the 

contact list 

• add the sender's name to the contact list based on a 
received e-mail id number 

This example assumes that the application 
30 session is available to the adaptor through a session 

id mechanism described elsewhere. Also, the example 
assumes the following : 

Populating fields in the session manager's 
database does the application and user provisioning. 


13499ROUS01U 8° 

•The standards based API's used here to interface 
with the email application (SMTP and IMAP4 ) 

•No special client software is assumed (or indeed 
possible in most cases) on the target. Since some 
5 channels may have inherent limitations from a user- 

interface point of view, i.e.: 

a) one-at-a-time menu selection capability, 

b) data entry capability is limited (to 
approximately 100 words) vocabulary for 

10 acceptable speaker-independent recognition 

The session manager described above has, 
relative to the application adaptor, the following 

functions : 

1. Maintains the end-user specific 

15 configuration. 

2. User authentication into the 
application. Using a session id, the. 
application adaptors can use the session 
manager to access applications, using 

20 existing sub- systems like APM. 

3. Dynamic session instance management. The 
session manager can be used to store 
dynamic session state information on behalf 
of the application adaptor. The "handle". 

25 into that state information is the session 

id, obtained through the PIC. 

4. User profile management. Profiles are 
created and populated via the MIC and BIC 
interface in the completed system, but 

30 would be manually populated for the interim 

release checkpoints, and for testing 
purposes. Web-based provisioning is assumed 
to be as provided by MASP 1.1. Examples of 
configuration fields on a per-user basis 

35 would consist of: 
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10 


15 


20 


81 

a) Predefined (by user) e-mail responses; 

b) Predefined (by user) appointment 
summaries and locations; 

c) List of enabled applications, and URI's 
on a per-channel basis; 

d) Time-out values for application access; 

e) Application specific instance fields 
(containers). For example "session-id" . 

To access the applications, the application 
adaptors must accomplish the following : 
Application : Calendar: 
Functions : 

a) Get appointment summaries (headers) 
based on session id and date 

b) Get appointment detail, based on 
session id, appointment date and .time 

c) Set an appointment, based on 
session id, appointment date and time, 
and input appointment data fields 

e-mail 


Application 
Functions : 


25 


30 


a) Set a mailbox to be current based 
on session id, and mailbox id 

b) Get the number of unread messages 
in all mailboxes, or in the specified 
mailbox, based on session id and 
mailbox name. 

c) Get message summaries, based on 
session id, mailbox name. Get 
summaries for all messages (unless 
unread-only flag is set) . Provision to 
do this incrementally is provided to 
account for device buffer limitations. 


35 Application : Contact List: 
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Functions : 


10 


a) Get names in contact list 
incrementally based on session id, and 
number of entries (limited by client's 
buffer size) 

c) Get detail on a given name, based 
on session id and contact name 

d) add a name to the contact list . 
based session id and contact name 


As noted above, the application adaptor 
consists of a set of Stateless Session Beans that 
communicate with the applications. The broker module 
consists of a MCML (XML multi-channel application 

15 flow) document that specifies the Finite State 

Machine (FSM) states that the application adaptors- 
require to implement the functionality specified. 

The device adaptors use the application 
adaptors to present device-specific drives the ASR- 

20 TTS engine (VoicePortal ) , in an application 

independent way. 

The application adaptors described here are 
implemented as Stateless Session Enterprise Java 
Beans deployed within a i Java-based application 

25 server, and communicate with the target applications 

on the "back-end". The EJB's abstract the application 
interface presented to the device adaptors and are 
written once per application such that different 
device adaptors without modification may use them. 

30 The user' s flow through the application is 

guided by the broker module which is an MCML (multi- 
channel mark-up language) XML document that contains 
references to the EJB's. It is the MCML document 
that guides the device adaptor in its sequence of 

35 calls to the EJB's, which are effectively action 
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methods used to generate dynamic content for the 
application flow. 

In this example, the following design 
guidelines were applied : 
5 1. Java (Sun's JDK 1.2.2) is used for 

device and application adaptor coding. 

2. The J2EE 2.0 specification for EJB 
interface and deployment is adhered to... 

3. Web Logic Server 5.1 provides the 

10 application server and container framework 

for these classes. The Personalization 
Server (v 2.0) provides the Web-based PIC 
(Personal Interaction Portal) features upon 
which the multi-channel PIC is based. 

15 4. The application adaptor EJB' s are 

stateless, in that any device-side method 
call can be made at any time. State is 
maintained outside the EJB' s, in the unique 
Session Manager. Therefore EJB' s can be 

20 replicated and clustered. 

5. The device adaptors are application 
independent. The same device adaptor should 
work transparently with multiple 
applications. They implement specific 

25 instances of the state machine described in 

the application-specific MCML document - 
see below. 

6. The application's workflow is contained 
within the MCML document that can be 

30 obtained by calling the application's EJB. 

This flow describes a set of states and 
associated controls and actions that the . 
device adaptor can choose to implement. 

7. All E JB' s must use the session manager 
35 to store state or instance information. No 
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instance variables are allowed. The EJB' s 
should be clusterable across different 
servers and operate with a single logical 
session manager. 
5 The following code is that of a Java bean 

for the calendar application 

/** 

* CalendarBean — implement the methods in this 
10 interface as well as providing 

* the implementation of the business methods. 
*@ 

*@version 1.0 * 
*/ 

15 package com. nortel .masp .mca . e jb; 

import javax. ejb.*; 

import j ava . rmi . Remote; 

import j ava . rmi . RemoteException; 

import javax. naming. InitialContext ; 
20 import j avax . naming . NamingExcept ion; 

import j ava . io . * ; 

import java.util.*; 

import j ava. text.*; 

import java.net .URL; 
25 import com. nortel .masp. mca. stateManagement . * ; 

import com. nortel .masp. mca. util . * ; 

import com. nortel .masp. mca. MCML. XMLTranslater ; 

//import org.xml .sax. *; 

//import org.xml . sax . helpers . * ; 
30 public class MyCalendarBean implements SessionBean{ 

static private String SESSIONID = 

"CalendarSessionUser IDCLIENT" ; 

static private String CONNECTURLSTR = 

"CalendarSessionConnectionURLStringCLIENT" ; 
35 static private String CALENDAR I D = 
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"CalendarUserlDCLIENT" ; 

static private String USERNAME 
Constants . MCA_U S E R I D_KE Y ; 

static private String PASSWORD = 
5 Constants .MCA_PASSWORD_KEY; 

static private String APPURL = 
Constants . MCML_APPURL_TAG ; 

static private String PORT = "port"; 
10 static private String DATE = "date"; 

static private String EVENT ID = "eventid"; 
static private String [] months t r= { "January" 
"February", "March", "April", "May", "June", "July", 
" Augus t " , " S ep t embe r " , 
15 "October", "November", "December"}; 

static private int m_GMT_offset = -5; // 
Eastern time of Canada 

private SessionContext ctx = null; 
private String userSessionld = null; 
20 private boolean loginSucceed; 

private boolean logoutSucceed; 
private String url; 
private String port; 
private String curDate; 
25 private String calendarld; 

private boolean bhasEvent; 
public void e jbActivate ( ) { 

log( f, CalendarBean activated") ; 

} 

30 public void ejbRemove(){ 

log ( "CalendarBean Removed"); 
// logout of Calendar 

} 

public void ejbPassivate ( ) { 
35 log ( "CalendarBean Passivate") ; 
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} 

/** 

* Sets the session context. 

5 * @param SessionContext 

*/ 

public void setSessionContext (SessionContext 
context) { 

10 log { "CalendarBean Context set"); 

ctx = context; 
} 

public void ejbCreateO throws CreateException { 
} 

15 public String 

getSummaries.(SessionStateManagerDef manager, 

Properties params) 

{ 

log( n ####################getSummaries() Inside 

20 EJB################# M ) ; 

SessionState state = 
manager . getCurrentState ( ) ; 

String theDate = 
params. get Property (DATE) ; 
25 Calendar localTime = 

Calendar .getlnstance (TimeZone . getDef ault () ) ; 

Integer year, month, day; 
int curYear = 

localTime. get (Calendar. YEAR) ; // because the default 
30 year from VXML is 2001 

year = new Integer (curYear ) ; 
///Integer ( theDate . substring (0, 4) ) ; 

month = new Integer ( 
theDate. substring (4, 6) ) ; 
35 day = new Integer ( 
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theDate . substring ( 6, 8)); 

// System. out .print ( "year = ") ; 

// System, out .print ( "month = "); 

// System. out .print ( "day = "); 

5 userSessionld = 

(String) state. get (SESSIONID) ; 

log(SESSIONID + "=" + userSessionld) 

url = 

(String) state. get (CONNECTURLSTR) ; 

10 

bhasEvent = false; 
String retStr - 
get Summaries (year . intValue ( ) , month . intValue ( ) , 
day . intValue ( ) ) ; 
15 log ("Result : ") ; 

log (retStr) ; 
if ( ! bhasEvent) 

retStr = null; 
if (retStr != null) 
20 { 

XMLTranslater translator = 

new XMLTranslater () ; 

try 
{ 

25 retStr = 

translator . translate (retStr, "calsummary. xsl" ) ; 

log("MCML output:"); 
log (retStr) ; 

} 

30 catch (Exception e) 

{ 

retStr = null; 

e .printStackTrace ( ) ; 

} 

35 } 
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log("##M################End of 
getSummariesO Inside EJB#################" ) ; 

return retStr; 

} 

5 public String getDetail (SessionStateManagerDef 

manager, Properties params) 
{ 

//log("####################getDetail () Inside 
EJB#################") ; 

10 

SessionState state — 
manager . getCurrentState () ; 

String theDate = 
params. getProperty (DATE) ; 
15 userSessionld = 

(String) state. get (SESSIONID) ; 

//log (SESSIONID + "=" + 

userSessionld) ; 

url = 

20 (String) state. get (CONNECTURLSTR) ; 

String eventld = 
(String) params. get ("UID") ; 

calendarld = 
(String) state. get ( CALENDAR I D ) ; 
25 log ("UID = " + eventld); 

bhasEvent = false; 
String retStr = 
getEvent (userSessionld, eventld) ; 

log ( "Result : ") ; 
30 log (retStr); 

if (ibhasEvent) 

retStr = null; 
if (retStr != null) 
{ 

35 XMLTranslater translator = 
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new XMLTranslater ( ) ; 

try 
{ 

retStr = 

5 translator .translate (retStr, "caldetail . xsl" ) ; 

log("MCML output:") 
log (retStr) ; 

} 

catch (Exception e) 

10 

{ 

retStr = null; 

e .printStackTrace ( ) 

} 

15 } 

log("####################End of 
getDetaiK) Inside E JB#################" ) ; 

return retStr; 

} 

20 public boolean login (SessionStateManagerDef 

manager, Properties params) 
{ 

SessionState state = 
manager . getCurrentState () ; 
25 String username = 

params . getProperty (USERNAME) ; 

if (username == null) 
username = 
(String) state . get (USERNAME) ; 
30 String password = 

params .getProperty (PASSWORD) ; 

if (password =— null) 
password = 
(String) state . get (PASSWORD) ; 
35 String port = 
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params . getProperty (PORT) ; 

String appURL = null; 

try 

{ 

5 appURL = 

(String) state. get (APPURL) ; 

log("appUrl = M + appURL); 

} 

catch (Exception e) 
10 { 

appURL = nuli; 

} 

if (appURL == null) 
15 appURL 
=params. getProperty (APPURL) ; 

log("appUrl = " + appURL); 

URL myUrl = null; 

try 

20 { 

myUrl = new URL (appURL); 

} 

//catch (Mai f ormedURLExcept ion e) 
catch (Exception e) 
25 { 

e iprintStackTrace ( ) ; 
return false; 

} 

port = toString (myUrl . getPort ( ) ) ; 
30 appURL = myUrl.getProtocol () + ":// 

+ myUrl.getHost () ; 

boolean bRet = login (appURL, port, 
username, password) ; 

if (bRet) 
35 { 
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state .put (SESSIONID, 

userSessionld) ; 

st ate. put (CONNECTURLSTR, 

url) ; 

5 state. put (CALENDARID, 

calendarld) ; 

} else { 

int at = 

username . indexOf ( " @ " ) ; 


10 


if( at > 0) { 


username = 

username . substring ( 0, at ); 
15 bRet = login (appURL, 

port, username, password) ; 

if (bRet) { 
state. put (SESSIONID, userSessionld) ; 
state. put (CONNECTURLSTR, url); 
20 state . put (CALENDARID, calendarld) ; 

} 

} 

} 

Log. log (Log. DEBUGGING, getClassO, . 
25 "########################### iPlanet Username =" + 

username + »##############»); 

return bRet; 

} 

/* * 

30 * Get a specific day's summaries from 

00:00:00 -> 23:59:59 

* @param int year 

* @param int month 

* @param int day 
35 */ 
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private String getSummaries (int year, int month, 
int day ) { 

log ( "userSessionID = " + userSessionld) ; 
System. out. print ("year=") ; 
5 System.out .print (year) ; 

System. out .print ("month=" ) ; 
System. out .print (month) ; 

System. out. print ("day=") ; 
System. out. print (day) ; 
10 String strRetrieveSummary = 

retrieveSummaryString (userSessionld, year, month, 
day) ; 

return urlConnection (strRetrieveSummary, 
15 "Summary") ; 

} 

/* * 

* Get a specific event based on session ID 
and event ID 

20 * @param String session ID 

* @param String event ID 
*/ 

private String getEvent (String sessionld, String 
eventld) { 

25 String strEvent = eventString (sessionld, 

eventld) ; 

return urlConnection ( strEvent, "Event") ; 

} 

//http: //wleey006 : 81/login. wcap?user.=wbin&password=ne 
30 w2day&ref resh=l&fmt-out=text/xml 

private String loginString (String url, String 
port, String user, String password) { 

StringBuffer buffer = new 
StringBuf fer (url) ; 


35 
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buf fer. append (":" ) . append (port ) . append ( "/login. wcap?" 

) ; 

buf fer . append ( "user^" ) .append (user) .append ("&") .appen 
d("password=") .append (password) ; 
5 buf fer .append ( "&ref resh=l&fmt-out=text/xml" ) ; 

return buf f er . toString ( ) ; 

} 

// 

http : //wleey006 : 81/ f etchevents_by_id . wcap?id=sessionI 
10 d&uid=eventId&rid=0&mod=l&calid=wbin&brief=0&fmt-out s = 
text/xml 

private String eventString (String sessionld, 
String eventld) { 

15 StringBuffer buffer = new 

StringBuf f er (url) ; 

buf fer .append (":" ) . append (port ). append ( "/fetchevents_ 
by_id.wcap? n ) ; 

buf fer. append ("id=") . append (sessionld) . append ("&" ) .ap 
20 pend("uid=") . append (eventld) ; 

buffer. append ("&rid=0") . append ( "&mod=l" ) . append (" &cal 
id=") .append (calendarld) ; 

25 buf fer . append ( M &brief=0&fmt-out=text/xml" ) ; 

return buf fer . toString () ; 

} 

//http: //wleey00 6: 81 / logout . wcap?id=n32nv9q3b2r5po32o 
30 q3&fmt-out=text/xml 

private String logoutString ( ) { 
StringBuffer buffer = new 
StringBuffer (url) ; 

buf fer .append (": ") . append (port ) . append ( "/logout .wcap? 
35 "); 


"'■4 
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buffer, append ("id=") . append (userSessionld) ; 
buffer • append ( " & f mt-out=text /xml " ) ; 
return buf f er . toString ( ) ; 

} 

5 //http: //wleey006 : 81/f etchcomponents_by_range . wcap?id 

=t9u9s6he2r5pu9b&dtstart=19990331T112233&dtend=200103 
31T112233&fmt-out=text/xml&maxResults=0 


10 


15 


25 


//retrieve components from calendar 


private String retrieveSummaryString (String id, 
£3 int year, int month, int day) { 

String start = getFormatedTime (year, month, 
day, 0, 0, 0) ; 


p String end = getFormatedTime (year, month, 

day, 23, 59, 59) ; 

StringBuffer buffer = new 
StringBuf fer (url) ; 


1 %# 

ru 

ru 20 

;i buffer. append (": ") .append (port) . append ( "/fetchcompone 


nts_by_range . wcap? " ) ; 

buf fer .append ("id=") .append (id) ; 

buffer . append ("&dtstart=") . append (start ) .ap 
pend ( "&dtend=" ) . append (end) ; 

buf fer .append ("&fmt-out=text/xml&maxResults==0") ; 

30 return buf fer . toString () ; 

} 

/* 

http : //myserver : 81/ 
storecomponents .wcap? id=34 2342 3asdf as f &calid= Johnl &dt 
35 start=19990101T103 
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000&dtend=19990101T113000&uid=001&summary=new_year_ev 
ent 

5 */ 

/* private String storeComponentString (String url, 
String port, String sessionld, String user, String 
password, 

10 String year, String month, String 

day, String eventld, String summary) { 

String start = getFormatedTime (year, month, 
day, 0, 0, 0); 


t 15 String end = getFormatedTime (year , month, 

day, 23, 59, 59); 

StringBuf fer buffer =' new 
StringBuf f er (url) ; 

20 buf fer . append (":" ) . append (port) . append ( "/storecompone 

nts . wcap?id=" ) . append (sessionld) ; 

buf fer . append ( "&dtstart=" ) . append ( start ). ap 
pend ( " &dtend=" ) . append (end) ; 

buf fer . append { "&uid= M ) . append (event Id) .appe 
25 nd("&summary=" ) . append (summary) ; 


return buf f er . toString { ) ; 

} 

30 */ 
/* 


35 


http : //myserver : 81/storeevents . wcap?id= l bu9p3eb8x5p2n 
m0q3 1 &calid=newcal 
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&uid=all_params&dtstart=19990811T093000Z&dtend=l 99908 
11T163000Z 

5 

&summary=all%20params-of-storeevents%20are%20included 
&location=Mountain-View&icsClass=conf idential 
10 &icsUrl= http://www.mycompany.com 

&duration=PT7H&desc=read%20the%2 0summary&status=0&isA 
llDay=l 

15 

&geo=37.39;- 

122 . 05&rrules="count%3D4%3Bf req%3Ddaily" ; "count%3D4 %3 
Bf req%3Dweekly" 

20 

&exrules="count%3Dl%3Bf req%3Dweekly%3Binterval%3D2%3B 
byday%3DTU%2CTH" 

25 &rdates=19991015T093000&exdates=19990813T093000&prior 
ity=10 

&relatedTos=<777>&resources=board;pro j ector&categorie 
s=MEETING 

30 

&contacts=Jane\, John&&alarmStart=l 99908 11T092500Z 

&alarmEmail=lucys@mycompany . com&orgEmail=j ane@mycompa 
ny . com; 

35 
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*/ 

/* private String storeEventString ( 
//////>///////){ 

5 

String start = get FormatedTime (year, month, 
day, 0, 0, 0) ; 

String end = get Format edTime ( year," month, 
10 day, 23, 59, 59); 

return buf f er . toString ( ) ; 

} 

*/ 


15 

/ * * 

* urlConnection to Calendar server with 
20 given URL, callType 

* @param String url for the server 

* @param String call type 

25 

*/ 

private String urlConnection (String strUrl, 
String call) { 

String retStr = null; 

30 try{ 

URL url = new URL(strUrl); 
//"http: //wleeyOO 6. ca.nortel.com: 81/login . wcap?user=w 
bin&password=new2day&refresh=l&fmt-out=text/xml n ) ; 

InputStream in = url . openStream ( ) ; 
35 Buf f eredReader buf Reader 
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= new Buf feredReader (new 


InputStreamReader (in) ) ; 

// DatalnputStream data_in = new 

5 DatalnputStream (in) ; 

java .util .Vector contents = new 
java.util .Vector ( ) ; 


10 StringBuffer xmlString = new 

StringBuf fer ( ) ; 


UP PrintWriter output = null; 

""-■•J ■ 

p String sessionLine = " " ; 


ru 15 

-i String logoutLine = ""; 


it 


String loginLine = " " ; 
String logoutLine = 
StringWriter strout = new 


\ U StringWriter { ) ; 

j.y 20 if (call, equals ("Login") ) { 

//output = new PrintWriter (new 


Buf f eredWriter (new FileWriter ( "login .xml" ))) ; 

output = new PrintWriter (strout ) ; 

25 } 

if (call .equals ( "Summary" )) { 

//output = new PrintWriter (new 
Buf f eredWriter (new FileWriter ( "Summary .xml" ) ) ) ; 
30 output = new PrintWriter (strout ) ; 


//log ( "PrintWriter is created for 

Summary .xml \n" ) ; 


35 
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10 


else { 

if (call. equals ("Event") ) { 

//output = new 
PrintWriter (new Buff eredWriter (new 
FileWriter ("Event .xml") ) ) ; 

output = new 

PrintWriter (strout) ; 

//log ("PrintWriter is 
created for Event . xml\n" ) ; 

} 

} 

lA String line ; 

y boolean bflag = false; 

y 

y 20 while((line = buf Reader . readLine () ) != 

3 null) { 


ru is 

id 


// Too dirty, too 


much if. 


log (line) ; 

25 contents. addElement (line) ; 

if (call. equals ("Login") ) { 
output .println (line) ; 

if (line . startsWith ( "<X-NSCP-WCAP-SESSION-ID>" ) ) 
30 sessionLine = line; // 

found the line that contains sesssionID 

else 

if (line . startsWith ( "<X-NSCP-WCAP-ERRNO>" ) ) 


35 loginLine = line; 
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else if 

{line.indexOf ( "<X-NS CP- WCAP- CALENDAR- I D>" ) >= 0) 

{ //get 

5 calendar ID 

int 

first = line.indexOf (">") + 1; 

int 

last = line. lastlndexOf ("<") ; 
10 calendarld = line . substring (first, last); 

log ("Calendar id = " + calendarld); 

} 

} 

else if( call. equals ("Event") ) 

15 

{ 

if 

(line.indexOf ("<START") >= 0) 

{ 

20 

bhasEvent = true; 

log ( "processing <START> </START>"); 

StringBuffer humanTime = new StringBuf fer () ; 

int 

25 last = line.indexOf ("</START>") ; 

String theTime = line . substring { 7 , last -1) ; 

log ( "TimeString = M + theTime); 

theTime = ToHumanTime (theTime) ; 

humanTime . append ( " <APPDATE > " ) ; 
30 humanTime . append (curDate) ; 

humanTime . append ( "</APPDATE>" ) ; 

line 

= humanTime . toString () ; 
output .println (line) ; 
35 humanTime = new StringBuf fer () ; 
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humanTirae . append ( "<APPTIME>" ) ; 
humanTime. append (theTime) ; 
humanTime . append ( "</APPTIME>" ) ; 


5 


: "4 

m is 


line 


= humanTime. toSt ring () ; 
output. println (line) ; 


10 (line . indexOf ( "<END" ) >= 0) 


} 

else if 


bhasEvent = true; 

log ("processing <END> </END>") ; 


StringBuf fer humanTime = new StringBuf fer () ; 

int 

last = line .indexOf ("</END>") ; 
j[U String theTime = line . substring (5, last -1); 

;=H 20 log("TimeString = " + theTime); 

ij3 > theTime - ToHumanTime (theTime) ; 

humanTime . append ( " <APPENDDATE > " ) ; 
humanTime . append (curDate) ; 
humanTime . append ( " < / APPENDDATE > " ) ; 

25 

= humanTime . toString ( ) ; 

output .println (line) ; 

30 humanTime = new StringBuf fer () ; 

humanTime . append ( " <APPENDT IME > " ) ; 
humanTime. append (theTime) ; 
humanTime . append ( " < / AP PENDT IME > " ) ; 


line 


35 


line 
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= humanTime . toString ( ) ; 
output .println (line) ; 

else 

output .println (line) ; 

5 > 

else if( call. equals ("Summary") ) 
{ 

if, 

(line . indexOf ( "<EVENT" ) >= 0) 


10 

= true; 

(line . indexOf ( "< /EVENT" ) >= 0) 
15 = false; 

line . indexOf ( "<START") >= 0) 


30 


bflag 

if 

bflag 

if (bflag && 
{ 


20 bhasEvent = true; 

log ("processing <START> </START>") ; 

StringBuffer humanTime = new StringBuf f er ( ) ; 


25 last = line. indexOf ( "</START>" ) ; 

String theTime = line . substring (7, last -1); 
log("TimeString = " + theTime); 


int 


theTime = ToHumanTime (theTime) ; 
humanTime . append ( "<APPDATE>" ) ; 
humanTime . append (curDate) ; 
humanTime . append ( "</APPDATE>" ) ; 


35 


line 
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= humanTime . toString () ; 


output .println (line) ; 
humanTime = new StringBuf f er ( ) ; 
humanTime . append ( "<APPTIME>" ) ; 
humanTime. append ( theTime ) ; . 
humanTime . append ( "</APPTIME>" ) ; 


10 


15 


= humanTime . toString ( ) ; 
output .println (line) ; 


output .println ( line) ; 


} 


} 

else 


line 


20 


else if ( 

call. equals ("Logout" )) { 

if (line.startsWith ( "<X-NSCP-WCAP-ERRNO>" ) ) 
= line; 


logoutLine 


25 


retStr = strout . toString () ; 


output .close () ; 


30 


if ( call. equals ("Login") ) { 


loginLine = 

getValue ( loginLine, "<X-NSCP-WCAP-ERRNO>" ) ; 


35 


// 


15 


20 
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if (loginLine . equals ("0") ) 

loginSucceed = 
loginLine. equals ("0") ? true: false; 


if( loginSucceed) 

userSessionld = 
getValue(sessionLine, "<X-NSCP-WCAP-SESSION-ID>" ) ; 

//log ("User Session 
ID = " + userSessionld + " And loginSucceed^" + 
loginSucceed) ; 

} 

/* 

if( call. equals ("Logout") ) { 
log ("Logout is 


10 


executed") ; 


logoutLine = 

getValue (logoutLine, "<X»NSCP-WCAP-ERRNO>" ) ; log("The 
logout line is : " + logoutLine) ; 

2 ? logoutSucceed = 

logoutLine. equals ("-1") ? true: false; 

} 

*/ 

buf Reader . close ( ) ; 
30 // log(retStr) ; 

return retStr; 
}catch (Exception ex) { 
} 

return null; 

35 } 
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* getValue to get session ID from input line 
*■ @param String line containning session ID 

* ©return String session ID 


10 


',0 


public String getValue (String selectedLine, 
String tag) { 


String idString « null; 
i ( u try { 

=51 ■ . 

:>cs ' 
'•■..i' 

//X-NSCP-WCAP-SESSION-ID> 

! . 

i=cfc 

ru 

I'U 20 //X-NSCP-WCAP-ERRNO 

ru 

//String temp = . 
"<X-NSCP-WCAP-SESSION-ID>"; 

25 idString = 

selectedLine . substring (tag. length ()) ; // get 
substring after <> 


idString = idString . substring { 0, 
30 idString . indexOf ('<»)); 

} 

catch ( Exception e ) { 


35 


e .printStackTrace ( ) ; 
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} 

return ids tring . trim ( ) ; 


> 

5 private String getFormatedTime (int year, int 

month, int day, int hour, int minute, int second) { 

StringBuffer dateTime = new 
StringBuf fer {""+year) ; 
10 if (month< 10) { 

dateTime. append {"0") ; 

} 

dateTime . append (month) ; 
if (day<10) { 

dateTime . append ("0") ; 

} 

dateTime. append (day) . append ( "T" ) ; 
if ( hour< 10) { 

dateTime. append ("0") ;// 

} 

dateTime. append (hour) ; 
if ( minute<10) { 

dateTime. append ("0") ; // 

} 

dateTime. append (minute) ; 
if ( second<10) 

dateTime. append ("0") ;// 
dateTime . append (second) ; 
log ("The time is = : "+dateTime . toString () ) 
return dateTime . toString () ; 


25 


30 


35 
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> 

/ * * 

* login (String, String, String, String) in 
the calendar with 

5 * @param String url of Calendar server 

* @param String port of the Calendar server 

* @param String username 

* @param String password 

, * Greturn boolean true login succeed, false 
means you are not lucky. 


10 


15 


20 


25 


V 


private boolean login (String url, String 
port, String user, String password) { 

this. url = url; 

this. port = port; 

String strLogin = loginString (url, 
port, user, password) ; 

log (strLogin) ; 
// login 

30 try{ 

urlConnection (strLogin, "Login") 
log ("User session ID = " + 

userSessionld) ; 

return loginSucceed; 
35 } catch (Exception ex) { 


i.l s 
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ex.printStackTrace () ; 
return false; 
} finally { 

// what should be put here.? 

5 } 

} 

/** 

* Convert Calendar Date in Start and End 
elements into speakable date 

10 * @param String dateStr 

20000909T17000000 to September 9, 2000 
*/ 

private String ToHumanDate (String theDate) 


j : y 15 StringBuffer dateBuf = new 


: >.4 


25 


30 


StringBuffer {) ; 


Integer year, month, day; 
fy year = new Integer ( 

rU 20 theDate. substring (0, 4)); 

ru 
g 

^ month = new Integer ( 

theDate . substring (4, 6) ) ; 


day = new Integer ( 
theDate. substring (6, 8) ) ; 

log ("ToHumanDate dateStr: " + 

theDate) ; 

dateBuf .append (months tr [month. intValue () - 1]); 


35 


dateBuf . append ( " 
") .append (day) .append (", ") . append (year ) ; 
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log ("Converted Date: " + 
dateBuf . toS tring ( ) ) ; 


•it? 

■'P 15 


30 


return dateBuf . toStr ing ( ) ; 


} 


* Convert the time in the START element into 
10 speakable time 

* Such as 20000911T150000Z to 8 AM On 
Spetember 11, 2000 


*/ 

private String ToHumanTime (String theDate) 

10 

:fr " ( - 

i : y 

I'y 20 log("ToHumanTime&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&& " ) . 

ry 

Q log("theDate =" + theDate); 

Calendar localTime = 
25 Calendar .getlnstance (TimeZone . getDef ault ()) ; 

int GMToffset = 
localTime. get (Calendar. ZONE_OFFSET) / 3600000; 


System. out .print ("GMT offset = "); 

Integer yearl, monthl/ dayl, hourl, 
minutel, secondl; 


35 


int year, month, day, hour, minute, 
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second; 

yearl = new Integer { 
theDate. substring (0, 4)); 

5 

monthl = new Integer ( 
theDate. substring (4, 6) ) ; 

dayl = new Integer ( 
10 theDate. substring (6, 8) ) ; 

hourl = new Integer ( 
theDate. substring (9, 11)) ; 

15 minutel = new Integer ( 

theDate. substring (11, 13)); 


.secondl = new Integer { 
theDate. substring (13, 15) ) ; 

year = yearl . intValue () ; 


20 


25 


30 


GMToffset; 


month = monthl .intValue () ; 
day = dayl. intValue () ; 
hour = hourl . intValue () - 1 

minute = minutel . intValue ( ) 

second = secondl . intValue ( ) 

if (hour < 0) 

{ 

hour += 24; 


35 
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day 


□ 


if (day < 0) 
{ 

5 month — ; 

if (month < 0) 
year — ; 

} 

} 

10 else if (hour > 24) 

hour 12; 
String timeTag = "AM"; 


''4 Integer daylnt = new Integer (day) ; 

fu 15 

^ String dayStr = daylnt . toString () ; 

Integer yearlnt = new Integer (year ) 

ru 

i s J| 20 String yearStr = yearlnt . toString ( ) 


if (hour > 12) 
.{ 

25 

timeTag = "PM" ; 
hour -= 12; 

30 } 

else if (hour == 12) 

timeTag = " "; 
35 StringBuffer timeStr = new 
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StringBuffer () ; 
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timeStr.append(toString(hour) ) ; 
if (minute > 0) 
t imeStr. append (": ") . append (toString (minute) ) ; 

if (second > 0) 
t imeStr. append ( " : ") . append (toString (second) ) ; 
3 timeStr.append(" "). append (timeTag) ; 

j : y 15 localTime . set (Calendar . YEAR, year) ; 

localTime. set (Calendar. MONTH, month - 


10 


: is 


ii 


i U 

□ 


l) ; 


20 localTime. set (Calendar . DAY_OF_MONTH, 

day) ; 

Date date = localTime . getTime () ; 

SimpleDateFormat fd = new 
25 SimpleDateFormat ( "EEEE, MMMMMMMMM- d, yyyy" ); 

curDate = fd. format (date) ; 

// log ("converted time: " + 

30 timeStr. toString () + 11 " + curDate); 

return timeStr . toString {) ; 

} 

private String toString (int value) 
{ 

35 Integer tmpvalue = new 
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Integer (value) ; 

return new 
String ( tmpvalue . toString ( ) ) ; 


} 


30 


logout () of the Calendar 

10 

V 

public void logout (){ 

String strLogout = logoutString ( ) ; 
15 log (strLogout) ; 

urlConnection (strLogout, "Logout") ; 
//return logoutSucceed; 

20 

} 

private void log (String s) 

{ 

25 Log. log (Log. DEBUGGING, getClass<), s) ; 

} 

} 

Fig 3 illustrates a full-blown system 
according to the invention including a session 
manager 80 and an authentication manager 90. The 
figure illustrates the different components of the 
full system as described above. It can be seen that 
the authentication manager 90 is shown as having 
multiple servlets within it. This is because each 
device type has- a separate authentication servlet to 


35 


10 
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accommodate the needs of that specific device type. 
Similarly, the DMI component 40 has multiple servlets 
within it — one servlet for each device type. The 
broker , module 30 is shown as two components - the 
5 software MCML script 30A and the finite state machine 

XML/XSLT engine 30B which executes the script 30A. 
The AMI component. 20 is depicted as two components — 
as application EJBs and authentication EJBs. Each 
group of EJBs has its specific function. The 
application EJBs provide the data to the broker 
module while the authentication EJBs provide the 
authentication data - required by the authentication 
manager. The authentication EJBs also access the 
applications but only to the extent required by the 
15 authentication manager. 

Also, as can be seen in Fig 3, the end user 
devices communicate with an extra layer between 
itself and the authentication manager. For WAP 
enabled devices, a WAP gateway 100A receives their 
20 data. For a PSTN telephone 50C, the user's voice 

first goes through a Voice XML engine 100B which 
converts the user's voice input into data 
recognizable by the other components. A dispatch 
servlet 110 sends the signals to their proper servlet 
25 in the authentication manager. 

For a regular PC 70, its authentication 
data has to travel through the APM (access policy * 
manager) authorization server 120 and then to the 
LDAP (lightweight directory access protocol) server 
30 130. 

To step through the process, the PSTN 
telephone, if its user desires access to an 
application, the sequence of steps are as follows : 
1. User dials up Voice Portal DN using a 

35 POTS phone 
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2. Voice Portal -static welcome page is 
invoked, and the server makes a request to 
the authentication servlet via the initial 
URL. 

3. Authentication servlet does not see a 
session key embedded in the request URL and 
therefore issues a challenge page 
appropriate to the device. It does this by- 
checking the user agent type and other 
information in the request header, and^by 
then fetching an MCML document that it 
translates through the appropriate XSL 
style sheet - which produces a Voice XML 
form, welcoming the user and asking for 
authentication (user id and password) . The 
links in this Voice XML document have a 
temporary authentication key embedded in 
them by the authentication servlet, to 
protect this initial transaction. 

4. Voice Portal begins to interpret the 
Voice XML script, which asks for the 
initial welcome prompt and login request. 
User listens to welcome prompt and to the . 
request for user id, and keys in or speaks 
the requested info (we can set this choice 
either way through Voice XML tags) . 

5. Voice Portal then interprets the user 
input and sends a request to the 
authentication servlet with the posted form 
data. The authentication servlet checks 
with APM and authenticates the user. If 
successful, it generates a session ID that 
will be appended to all subsequent 
transaction URLs with our server for this 
session . 
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6. The authentication servlet continues 
to interpret the PIC MCML flow', which asks 
it to call the PIC EJB, to get a list of 
enabled applications from the 
Personalization Server. 

7. The EJB returns the list, filtered by 
the EJB adaptor into MCML, which is 
embedded into the PIC MCML template. 

8. The list has associated hyperlink URLs 
that are filtered through the session 
manager, to append a session ID (URL 
rewriting) . 

9. The MCML is translated to Voice XML by 
the XSLT processor using the VoiceXML style 
sheet. It is then served to the Voice 
Portal for interpretation. 

10,. The user hears the list (TTS ) and 

selects an application. This causes the 
Voice Portal to send an HTTP request to the 
authentication servlet. 

.1. The servlet now sees a session ID 

appended to the URL, and checks its 
validity. If valid, it passes the request 
on to the device adaptor servlet (DA) , 
unchallenged. 

2. The DA then retrieves the MCML page 
for that particular app. (this was encoded 
in the request URL) . 

3. It scans for dynamic placeholder tags, 
and makes calls to the application specific 
adaptor EJB's (method names and parameters 
are embedded in MCML) to generate dynamic 
application content if required. 

4. The device adaptor EJB attempts to 
retrieve a client connection to the app. 
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from the Session Manager. 

15. The session manager cannot find the 
client, and throws an exception, which is 
passed on the DA. 

16. The DA identifies this exception and 
invokes the authentication EJB associated 
with this app. which connects using the 
stored credentials, and then saves a client 
connection in the Session manager (Single 
sign-on) . 

17. The device adaptor then re-tries the 
initial call to the application adaptor, 
which will now successfully retrieve the 
client connection from the session manager. 

18. The EJB connects to the app to get 
content. 

19. This content is returned by the EJB' s 
as MCML, through the EJB-DA interface 
object, which converts the data to MCML. 
The DA merges this MCML with the static 
MCML page template. 

20. The DA then filters all URLs through 
the Session manager to append session ID. 
The link to the next MCML page is also 
generated and appended to the URLs here. 

21. The DA then translates the MCML though 
XSLT to get a Voice XML, which is served 
back to the client. 

22. Voice Portal client interprets the 
returned page, and cycles through the 
process starting at step 11 above (without 
the initial authentication exceptions) , 
invoking further MCML pages . 

23. The cycle continues until the MCML FSM 
script reaches an exit state, at which 


10 


15 
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point the DA closes the connection by 
deleting the session - by making a call to 
the Session manager. Further requests will 
then require the authentication cycle to 
5 kick-in. User inactivity time-outs can also 

occur if the user hangs up, or fails to 
respond within a prescribed delay. 
For a WAP enabled cellular telephone or a 
WAP enabled PDA, the process is as follows : 

1- User accesses WAP gateway via Remote Access 
Server dialup programmed into the WAP handset. User 
selects a link to access the multi-channel system. 

2 - As a result, WAP gateway makes a request to 
the authentication servlet. 

3. Authentication servlet does not see a 

session ID embedded in the request URL and 
therefore issues a challenge page appropriate to 
the device. It does this by checking the user agent 
type in the header, and by then fetching an MCML 
document that it translates through the appropriate 
XSL style sheet - which produces a HDML or WML 
deck, welcoming the user and asking for 
authentication (user id and password) . The links in 
this document have a temporary authentication key 
25 embedded in them by the authentication servlet, to 

protect this initial transaction. Care must be 
taken not to exceed the limitations on URL size 
inherent to some WML and HDML browsers. 
4 - The handset browser displays the card deck, 

which asks for the initial welcome prompt and login 
request. User keys in credentials. These are sent 
through WAP gateway as a request to the 
authentication servlet with the posted form data. 
The authentication servlet checks with APM and 
authenticates the user. If successful, it generates 
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a session ID that will be appended to all 
subsequent transaction URLs with our server for 
this session. 

5. The authentication servlet continues to 

5 interpret the PIC MCML flow, which asks it to call 

the PIC EJB, to get a list of enabled applications 
from the Personalization Server. 

6. The EJB returns a list of application, 
filtered by the EJB adaptor to produce MCML, which 

10 is embedded into the PIC MCML template. 

7. The list has associated hyperlink URLs that 
are filtered through the session manager, to append 
a session ID (URL rewriting) . 

8. The MCML is translated to WML or HDML by 
15 the XSLT processor using the appropriate style 

sheet. It is then served to the WAP gateway for 
forwarding to the handset. 

9. The user sees the list and selects an 
application. This causes the WAP gateway to send a 

20 HTTP request to the authentication servlet. 

10. The servlet now sees a session ID appended 
to the URL, and checks its validity. If valid, it 
passes the request on to the device adaptor servlet 
(DA) , unchallenged. 

25 11. The DA then retrieves the MCML page for 

that particular app. (this was encoded in the 
request URL) . 

12. It scans for dynamic placeholder tags, and 
makes calls to the application specific adaptor 

30 EJB's (method names and parameters are embedded in 

MCML) to generate dynamic application content if 
required. 

13. The device adaptor EJB attempts to retrieve 
a client connection to the app. from the Session 

35 Manager. 
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14. The session manager cannot find the client, 
and throws an exception, which is passed on the DA. 

15. The DA identifies this exception and 
invokes the authentication EJB associated with this 

5 app. which connects using the stored credentials, 

and then saves a client connection in the Session 
manager (Single sign-on) . 

16. The device adaptor then re- tries the 
initial call to the application adaptor, which will 

10 now successfully retrieve the client connection 

from the session manager. 

17. The EJB connects to the app to get content. 

18. This content is returned by the EJB' s as 
15 MCML, through the EJB- DA interface object, which 

converts the data to MCML. The DA merges this MCML 
with the static MCML page template. 

19. The DA then filters all URLs through the 
Session manager to append session ID. The link to 

20 the next MCML page is also generated and appended 

to the URLs here,. 

20. The DA then translates the MCML though XSLT 
to get WML a HDML deck, which is served back to the 
client . 

25 21. WAP gateway forwards the returned deck to 

handset, and cycles through the process starting at 
step 10 (but omitting any initial authentication 
exceptions) above, invoking further MCML pages. 
22. The cycle continues until the MCML FSM 

30 script reaches an exit state, at which point the DA 

closes the connection by deleting the session - by 
making a call to the Session manager. Further 
requests will then require the authentication cycle 
to kick-in. User inactivity time-outs can also 

35 occur if the user disconnects, or fails to respond . 
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within a prescribed delay. 

A person understanding the above-described 
invention may now conceive of alternative designs, 
using the principles described herein. All such 
5 designs which fall within the scope of the claims 

appended hereto are considered to be part of the 
present invention. 


